参考原文链接:
http://blog.csdn.net/maopig/article/details/6665250
http://www.cnblogs.com/qingquan/archive/2011/07/14/2106834.html

RTSP实时流协议

多媒体播放控制协议，TCP/IP协议体系中的一个应用层协议，用来使用户在播放从因特网下载的实时数据时能够进行控制。（暂停，播放，后退，前进）

RTSP特性

• 流控分离：从控制逻辑上来说RTSP和FTP相似，控制流和数据流是分开的。
• 可扩展性：因为RTSP协议是基于文本的协议所以其具有较强的可扩展性。
• 安全：RTSP 使用网页安全机制。

RTSP协议条件

实现控制功能 除协议外还需

• 1 媒体播放器(media player)
• 2 媒体服务器(media server)

RTSP 报文结构

RTSP有 两类报文：请求报文和响应报文。请求报文是指从客户向服务器发送请求报文，响应报文是指从服务器到客户的回答。

由于RTSP 是面向正文的(text-oriented)，因此在报文中的每一个字段都是一些 ASCII 码串，因而每个字段的长度都是不确定的。

请求报文

响应报文

协议特点

• 可扩展性：新方法和参数很容易加入RTSP。
• 易解析：RTSP可由标准 HTTP或MIME解析器解析。
• 安全：RTSP使用网页安全机制。
• 独立于传输：RTSP传输通道，可使用不可靠数据包协议（UDP）或可靠数据包协议（RDP），如要实现应用级可靠，可使用诸如TCP的可靠流协议。
• 记录设备控制：协议可控制记录和回放设备。
• 适合专业应用：通过SMPTE 时标，RTSP支持帧级精度，允许远程数字编辑。
• 演示描述中立：协议未强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少需包含一个RTSP URI。
• 代理与防火墙友好：协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个“缺口”。
• 适当的服务器控制：如用户启动一个流，则也可以停止一个流。
• 传输协调：实际处理连续媒体流前，用户可协调传输方法。
• 性能协调：如基本特征无效，则必须有一些清理机制让用户决定那种方法不生效。这允许用户提出适合自己的界面。

与HTTP协议流控制协议的区别

• 都使用纯文本来发送信息，语法类似
• RTSP协议是有状态的协议，HTTP是无状态的协议

协议的状态是指下一次传输数据的时候能考虑到这次传输信息的状态。也有是说有状态协议以前的请求导致协议所处的状态会影响后续的状态，协议会根据上一个状态创建上下文。

• http协议里就是无状态协议不用考虑上下文；每个请求都是与服务器的独立连接，即下一次请求到来的时候协议不用维护这次请求中客户机-服务器间交互的信息。
• RTSP通过维护一个session来维护其状态的转换

协议实现

1.初始化

在建立连接之前，客户端应向服务器提出测试请求，即要求服务器向客户端发送相应的测试数据包。初始化的目的，是为了获取客 户端和服务器之间的一些网络参数，估测基本网络状况，并以此选择相应的网络传输协议，使客户端获得最佳观看效果。
接到这个请求之后，服务器将根据自身情况进行如下测试：

• 利用同客户端建立的RTSP通道，采用TCP协议，下发测试数据包。
• 采用UDP协议，向客户端下发测试数据包。
  测试数据包仅做测试用，上面带有相应的时间和顺序信息，其内部数据并无任何意义。
  需要向RTSP增加一个新的方法TEST，以支持这种传输前的测试工作。

2.TCP传输

如果在TCP测试中，客户端反馈良好，即丢包率在可承受范围之内，并且在规定时间内到达，那么就认为客户端同服务器之间的 网络状况良好， 可以采用RTP over TCP的方式发送数据。由于TCP没有丢包（其自身具有重传机制），网络状况又属于良好，因此客户端将有较高的视听享受。
当子网内存在防火墙时，就需要采用RTSP附加数据传输方式。即把音视频数据直接打包，在RTSP通信信道内传输。这种传 输方式也存在一定的问题：

• 传输过程中，只是把音视频文件当成一个普通文件来处理，而没有考虑到它的音视频特性，不利于以后的扩展。
• 音频与视频文件没有分离，不利于某些特殊需求的场合。例如，客户端需要对音、视频做不同的处理。
• 客户端的反馈和RTSP的控制信息也是通过同一条RTSP信道传送，因此控制效率不高。
  因此，一般情况下，都默认使用RTP over TCP的方式发送数据。

3.UDP传输

如果在TCP测试中，客户端的反馈存在比较大的问题，即网络情况不理想，就应该考虑进行UDP测试。
目前初步采取的措施，在服务器端准备了两种码率的视频文件——高码率和低码率。
收到客户端的TEST方法后，将采用UDP协议下发测试包。采取的策略是每间隔2秒，下发一个1500字节的UDP数据 包。当丢包率处于一定范围（75％～85％）之内，就认为客户端的网络状况基本良好，可以下发高码率的电影文件;否则，认为测试不成功，由于网络状况的限 制，仅对客户端下发低码率的电影文件。
在基于UDP的播放过程中，可能会出现轻微的马赛克，这是完全可以接受的。这些马赛克出现的主要原因是：

• 不可靠连接造成的网络丢包，为客户端被动丢包。
• 高质量文件（DVD－>MP4）的高数据量，使得客户端解码线程和显示线程出现拥塞，从而出现客户端主动丢包。
  但从整体而言，UDP传输消耗的带宽，要比TCP小许多。在一般的视频点播要求下，使用基于UDP的传输线路，是完全可以 满足要求的。

4.传输反馈

在传输过程中，主要采取的方式是RTP over TCP或RTP over UDP，因此，在RTP端口之外，还存在一个回传端口RTCP。
在服务器收到客户端的RTCP回传信息后，需要对其进行判断。如果客户端的丢包率、解码率等指标在一定限度之下，就认为目 前传送的视频文件可令客户端获得最大程度的音视频享受;否则，考虑改为传输更低码率的视频文件或放弃这次RTSP会话，以避免更大范围的拥塞。

5.实际效果

采取如上方法设计的系统，可以满足视频点播的基本要求，避免了服务器视频文件下发的盲目性，同时使客户端应用效果最好