RTSP
RTSP（实时流传输协议）是TCP/IP协议体系中的一个应用层协议，由哥伦比亚大学、网景和RealNetworks公司提交的IETF RFC标准，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据，RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输，HTTP与RTSP相比，HTTP传送HTML而RTSP传送的是多媒体数据，HTTP请求由客户机发出，服务器作出响应；使用RTSP时客户机和服务器都可以发出请求，即RTSP可以是双向的。
RTSP基本介绍[ ]
- RTSP是用来控制声音或影像的多媒体串流协议并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似但并不特别强调时间同步，所以比较能容忍网络延迟。
- 而前面提到的允许同时多个串流需求控制，除了可以降低服务器端的网络用量，更进而支持多方视讯会议，因为与HTTP1.1的运作方式相似所以代理服务器的快取功能也同样适用于RTSP，并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。
- 实时流协议是应用级协议，控制实时数据的发送，RTSP提供了一个可扩展框架，使实时数据如音频与视频，的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。
- 实时流协议建立并控制一个或几个时间同步的连续流媒体，尽管连续媒体流与控制流交换是可能的，通常它本身并不发送连续流，也就是说RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，此外可使用无连接传输协议，如UDP，RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。
RTSP协议支持的操作[ ]
- 从媒体服务器上检索媒体：用户可通过HTTP或其它方法提交一个演示描述，如演示是组播演示式就包含用于连续媒体的的组播地址和端口，如演示仅通过单播发送给用户，用户为了安全应提供目的地址。
- 媒体服务器邀请进入会议：媒体服务器可被邀请参加正进行的会议，或回放媒体、或记录其中一部分或全部，这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。
- 将媒体加到现成讲座中：如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用，如HTTP/1.1中类似，RTSP请求可由代理、通道与缓存处理。
RTSP协议特点[ ]
- 可扩展性：新方法和参数很容易加入RTSP。
- 易解析：RTSP可由标准HTTP或MIME解析器解析。
- 安全：RTSP使用网页安全机制。
- 独立于传输：RTSP可使用不可靠数据报协议（EDP）、可靠数据报协议（RDP）；如要实现应用级可靠可使用可靠流协议。
- 多服务器支持：每个流可放在不同服务器上，用户端自动与不同服务器建立几个并发控制连接，媒体同步在传输层执行。
- 记录设备控制：协议可控制记录和回放设备。
- 流控与会议开始分离：仅要求会议初始化协议提供，或可用来创建惟一会议标识号，特殊情况下可用SIP或H.323来邀请服务器入会。
- 适合专业应用：通过SMPTE时标，RTSP支持帧级精度，允许远程数字编辑。
- 演示描述中立：协议没强加特殊演示或元文件，可传送所用格式类型；然而演示描述至少必须包括一个RTSP URL。
- 代理与防火墙友好：协议可由应用和传输层防火墙处理，防火墙需要理解SETUP方法为UDP媒体流打开一个“缺口”。
- HTTP友好：此处RTSP明智地采用HTTP观念，使现在结构都可重用，结构包括Internet内容选择平台，由于在大多数情况下控制连续媒体需要服务器状态，RTSP不仅仅向HTFP添加方法。
- 适当的服务器控制：如用户启动一个流，必须也可以停止一个流。
- 传输协调：实际处理连续媒体流前，用户可协调传输方法。
- 性能协调：如基本特征无效必须有一些清理机制让用户决定哪种方法没生效，这允许用户提出适合的用户界面。
RTSP协议结构[ ]
RTSP是一种文本协议，采用UTF-8编码中的ISO 10646字符集，一行可通过CRLF终止但接收端需要做好解释CR和LF作为一行终止符的准备，关于头字段概述如下： Header Type Support Methods
Accept R opt. entity
Accept-Encoding R opt. entity
Accept-Language R opt. all
Allow R opt. all
Authorization R opt. all
Bandwidth R opt. all
Blocksize R opt. All but OPTIONS,TEARDOWN
Cache-Control G opt. SETUP
Conference R opt. SETUP
Connection G req. all
Content-Base E opt. entity
Content-Encoding E req. SET_PARAMETER
Content-Encoding E req. DESCRIBE,ANNOUNCE
Content-Language E req. DESCRIBE,ANNOUNCE
Content-Length E req. SET_PARAMETER,ANNOUNCE
Content-Length E req. entity
Content-Location E opt. entity
Content-Type E req. SET_PARAMETER,ANNOUNCE
Content-Type R req. entity
CSeq G req. all
Date G opt. all Retry-After R opt. all
RTP-Info R req. PLAY
Scale Rr opt. PLAY,RECORD
Session Rr req. All but SETUP,OPTIONS
Server R opt. all
Speed Rr opt. PLAY
Transport Rr req. SETUP
Unsupported R req. all
User-Agent R opt. all
Via G opt. all
类型"g"表示请求和响应中的通用请求头；
类型“R”表示请求头；类型“r”表示响应头；
类型"e"表示实体头字段。在“support”一栏中标有“req.”的字段必须由接收者以特殊的方法实现；
而“opt.”的字段是可选的。注意，不是所有“req.”字段在该类型的每个请求中都会被发送。
“req.”只表示客户机（支持响应头）和服务器（支持请求头）必须执行该字段。最后一栏列出了关于头字段产生作用的方法；
其中“entity”针对于返回一个信息主体的所有方法。
RTSP协议基本信息[ ]
- RTSP是基于文本的协议，采用ISO 10646字符集，使用UTF-8编码方案，行以CRLF中断但接收者本身可将CR和LF解释成行终止符，基于文本的协议使以自描述方式增加可选参数更容易。由于参数的数量和命令的频率出现较低，处理效率没引起注意。
- ISO 10646字符集避免敏感字符集切换，但对应用来说不可见，RTCP也采用这种编码方案，带有重要意义位的ISO 8859-1字符表示如100001x 10x x x x x x，RTSP信息可通过任何低层传输协议携带。
- 请求包括方法、方法作用于其上的对象以及进一步描述方法的参数。方法也可设计为在服务器端只需要少量或不需要状态维护。当信息体包含在信息中，信息体长度由如下因素决定：
- 不管实体头段是否出现在信息中，不包括信息体的响应，信息总以头段后第一个空行结束。
- 如出现内容长度头段，其值以字节计，表示信息体长度。如未出现头段，其值为零。
- 服务器关闭连接，注意RTSP目前并不支持HTTP 1.1“块”传输编码，需要有内容长度头，假如返回适度演示描述长度，即使动态产生，使块传输编码没有必要，服务器也应该能决定其长度。如有实体，即使必须有内容长度，且长度没显式给出，规则可确保行为合理。
- 从用户到服务器端的请求信息在第一行内包括源采用的方法、源标识和所用协议版本。RTSP定义了附加状态代码，但没有定义任何HTTP代码。
编辑本段RTSP实体
- 如不受请求方法或响应状态编码限制，请求和响应信息可传输实体，实体则由实体头文件和实体体组成，有些响应仅包括实体头。在此，根据谁发送实体、谁接收实体，发送者和接收者可分别指用户和服务器。
- 实体头定义实体体可选元信息，如没有实体体，指请求标识的资源。扩展头机制允许定义附加实体头段，而不用改变协议，但这些段不能假定接收者能识别。不可识别头段应被接收者忽略，而让代理转发。
RTSP请求可以几种不同方式传送[ ]
- 持久传输连接，用于多个请求/响应传输。
- 每个请求/响应传输一个连接。
- 无连接模式。
- 不像HTTP，RTSP允许媒体服务器给媒体用户发送请求。然而这仅在持久连接时才支持，否则媒体服务器没有可靠途径到达用户，这也是请求通过防火墙从媒体服务器传到用户的惟一途径。