RTSP协议介绍

1. 实 时流协议RTSP

RTSP[3] 协 议以客户服务器方式工作，它是一个多媒体播放控制协议，用来使用户在播放从因特网下载的实时数据时能够进行控制，如：暂停/ 继 续、后退、前进等。因此 RTSP 又称为“ 因特网录像机遥控协议” 。

1.1.    RTSP 协 议简介

要 实现 RTSP 的控制功能，不仅要有协议，而且要有专门的媒体播放器(media player) 和 媒体服务器(media server) 。媒体服务器与媒体播放器的关系是服务器与客户的关系。

媒 体服务器与普通的万维网服务器的最大区别就是媒体服务器支持流式音频和视频的传送，因而在客户端的媒体播放器可以边下载边播放（需要先缓存一小段时间的节目）。但从普通万维网服务器下载多媒体节目时，是先将整个文件下载完毕，然后再进行播放。

图1 RTSP 与RTP 和RTCP 的关系

RTSP 仅仅是使媒体播放器能控制多媒体流的传送。因此，RTSP 又称为带外协议，而多媒体流是使用 RTP 在带内传送的。

1.2.     RTSP 的 报文结构

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

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

RTSP 报 文由三部分组成，即开始行、首部行和实体主体。在请求报文中，开始行就是请求行，RTSP 请求报文的结构如图2 所 示。

图2 RTSP 请求报文的结构

RTSP 请 求报文的方法包括：OPTIONS 、DESCRIBE 、SETUP 、TEARDOWN 、PLAY 、PAUSE 、GET_PARAMETER 和SET_PARAMETER 。RTSP 请 求报文的常用方法及作用如表1 所示。

表1 RTSP 请求报文的常用方法及作用

方法	作用
OPTIONS	获得服务 器提供的可用方法
DESCRIBE	得到会话 描述信息
SETUP	客户端提 醒服务器建立会话，并确定传输模式
TEARDOWN	客户端发 起关闭请求
PLAY	客户端发 送播放请求

响 应报文的开始行是状态行，RTSP 响应报文的结构如图3 所示。

图3 RTSP 响应报文的结构

1.3.     RTSP 交 互过程

C 表 示RTSP 客户端，S 表示RTSP 服务端

① C->S: OPTION request            // 询问S 有 哪些方法可用

S->C: OPTION response        //S 回 应信息中包括提供的所有可用方法

② C->S: DESCRIBE request      // 要求得到S 提供 的媒体初始化描述信息

S->C: DESCRIBE response      //S 回 应媒体初始化描述信息，主要是sdp

③ C->S: SETUP request         // 设置会话属性，以及传输模式，提醒S 建 立会话

S->C: SETUP response         //S 建 立会话，返回会话标识符及会话相关信息

④ C->S: PLAY request          //C 请求播放

S->C: PLAY response          //S 回 应请求信息

S->C: 发 送流媒体数据

⑤ C->S: TEARDOWN request     //C 请 求关闭会话

S->C: TEARDOWN response     //S 回应请求

上 述的过程是标准的RTSP 流程，其中第3 步和第4 步是必需的。

RTSP ，实时流协议，是一个C/S 多媒体节目协议， 它可以控制流媒体数据在IP 网络上的发送，同时提供用于音频和视频流的“VCR 模式” 远程控制功能，如停止、快进、快退和定位。同时RTSP 又是一个应用 层协议 ，用来与诸如RTP 、RSVP 等更低层的协议一起，提供基于Internet 的整套流化服务。基于RTSP 协议流媒体服务器的实现方案可以让流媒体在IP 上自由翱翔。

RTSP 协议

1 ．协议特点

RTSP 协议具有如下的特点：

● 可扩展性：新方法和参数很容易加入RTSP 。

● 易解析：RTSP 可由标准 HTTP 或MIME 解析器解析。

● 安全：RTSP 使用网页安全机制。

● 独立于传输：RTSP 传输通道，可使用不可靠数据包协议（UDP ）或可靠数据包协议（RDP ），如要实现应用级可靠，可使用诸如TCP 的可靠流协议。

● 记录设备控制：协议可控制记录和回放设备。

● 适合专业应用：通过SMPTE 时标，RTSP 支持帧级精度，允许远程数字编辑。

● 演示描述中立：协议未强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少需包含一个RTSP URI 。

● 代理与防火墙友好：协议可由应用和传输层防火墙处理。防火墙需要理解SETUP 方法，为UDP 媒体流打开一个“ 缺口” 。

● 适当的服务器控制：如用户启动一个流，则也可以停止一个流。

● 传输协调：实际处理连续媒体流前，用户可协调传输方法。

● 性能协调：如基本特征无效，则必须有一些清理机制让用户决定那种方法不生效。这允许用户提出适合自己的界面。

2 ．同其他协议的关系

RTSP 在功能上与HTTP 有重叠，最明显的交叉是在流媒体内容的发布上—— 大多是通过网页进行的。目前的协议规范同时允 许网页服务器和流媒体服务器支持RTSP 实现。例如，演示描述可通过HTTP 或RTSP 获取，这样减少了基于浏览器情况下的往返传递时间，同时也支持独立的RTSP 服务器与不依赖HTTP 的客户端通信。

但是，RTSP 与HTTP 的本质差别在于以下五个方面

● RTSP 和HTTP 是两个不同的协议，它们采用不同的方法和协议标志符。

● RTSP 协议的数据发送不占用协议带宽，并且以不同的协议发送。

● HTTP 是一个不对称协议，客户端发出请求，服务器应答。在RTSP 中，客户端和服务器都可发出请求，且请求是有状态的。

● HTTP 是一个无状态协议，而RTSP 在任何情况下，必须保持一定状态，以便在请求确认后的很长时间内，仍可设置参数，控制媒体流。

● RTSP 使用ISO 10646 （UTF-8 ）定义，而不使用ISO 8859-1 定义，保持与当前的HTML 一致。

虽然大多数实时媒体采用RTP 作为传输协议，但RTSP 并不绑定RTP 。

重用HTTP 的功能至少在两个方面有好处: 安全和代理。由于要求非常接近，因此在缓存、代理和授权上采用HTTP 功能是有 价值的。

 

RTSP 的实现

RTSP 功能实现结构如下图所示。

 

 

RTSP 在流媒体传输过程中，仅仅为双方建立连接，并不具备任何智能，也就不能很好地应付难以预料的网络状态。因此，必须 在它原有功能的基础上，进行改进。

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 、实际效果

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

引入智能流技术

随 着针对流媒体技术研究的不断深入，简单的流媒体实现已经不能满足人们日益增长的网络文化需求。即使在宽带条件下，当网络用户达到一定限额时，简单的流媒体 技术将面临着网络拥塞、丢包等常见的网络问题。因此，如何在网络出现异常的情况下，依然保证客户端音视频享受的最大化， 就成为现在研究的热点。

一种解决方法是服务器减少发送给客户端的数据而阻止再缓冲，在RealSystem 5.0 中，这种方法称为“ 视频流瘦化” 。这种方法的限制是RealVideo 文件必须是一种数据速率设计，结果可通过抽取内部帧扩展到更低速率，导致质量较低，离原始数据速率越远，质量越差。

另一种解决方法是根据不同连接速率创建多个文件，根据用户连接，服务器发送相应文件，这种方法带来制作和管理上的困难，而且，用户连接是动态变化的，服务器也无法实时协调。

智能流技术通过两种途径克服带宽协调和流瘦化: 首先，确立一个编码框架，允许不同速率的多个流同时编码，合并到同一个文件 中；第二，采用一种复杂客户/ 服务器机制探测带宽变化。

针对软件、设备和数据传输速度上的差别，用户以不同带宽浏览音视频内容。为满足客户要求，Real Networks 公 司编码、记录不同速率下媒体数据，并保存在单一文件中，此文件被称为智能流文件，即创建可扩展流式文件。当客户端发出请求时，它将其带宽容量传给服务器， 媒体服务器根据客户带宽将智能流文件相应部分传送给用户。以此方式，用户可使用最优质的传输，制作人员只需要压缩一次，管理员也只需要 维护单一文件，而媒体服务器根据所得带宽自动切换。智能流通过描述Internet 上变化的带宽特点来发送高质量媒体并保证其 可靠性，并对混合连接环境的 内容授权提供了解决方法。这样流媒体实现方式如下：对所有连接速率环境创建一个文件。在混合环境下以不同速率传送媒体。根据网络的变化情况，无缝切换到其 他速率。关键帧优先，音频比部分视频帧数据更重要，向后兼容老版本RealPlayer 。

端口说明：554 端口默认情况下用于“Real Time Streaming Protocol” （实时流协议，简称RTSP ），该协议是由RealNetworks 和Netscape 共同提出的，通过RTSP 协议可以借助于 Internet 将流媒体文件传送到RealPlayer 中播放，并能有效地、最大限度地利用有限的网络带宽，传输的流媒体文件一般是Real 服务器发布 的，包括有.rm 、.ram 。如今，很多的下载软件都支持RTSP 协议，比如FlashGet 、影音传送带等等。

　　端口漏洞：目前，RTSP 协议所发现的漏洞主要就是RealNetworks 早期发布的Helix Universal Server 存在缓冲区溢出漏洞，相对来说，使用的554 端口是安全的。

　　操作建议：为了能欣赏并下载到RTSP 协议的流媒体文件，建议开启554 端口。

　　1024 端口

　　端口说明：1024 端口一般不固定分配给某个服务，在英文中的解释是“Reserved” （保留）。之前，我们曾经提到过动态端口的范围是从 1024 ～65535 ，而1024 正是动态端口的开始。该端口一般分配给第一个向系统发出申请的服务，在关闭服务的时候，就会释放1024 端口，等待其他 服务的调用。

　　端口漏洞：著名的YAI 木马病毒默认使用的就是1024 端口，通过该木马可以远程控制目标计算机，获取计算机的屏幕图像、记录键盘事件、获取密码等，后果是比较严重的。

　　操作建议：一般的杀毒软件都可以方便地进行YAI 病毒的查杀，所以在确认无YAI 病毒的情况下建议开启该端口。

　　1080 端口

　　端口说明：1080 端口是Socks 代理服务使用的端口，大家平时上网使用的WWW 服务使用的是HTTP 协议的代理服务。而Socks 代理服务 不同于HTTP 代理服务，它是以通道方式穿越防火墙，可以让防火墙后面的用户通过一个IP 地址访问Internet 。Socks 代理服务经常被使用在局域网中，比如限制了QQ ，那么就可以打开QQ 参数设置窗口，选择“ 网络设置” ，在其中设置Socks 代理服务（如图1 ）。另外，还可以通过安装Socks 代 理软件来使用QQ ，比如Socks2HTTP 、SocksCap32 等。

　　端口漏洞：著名的代理服务器软件WinGate 默认的端口就是1080 ，通过该端口来实现局域网内计算机的共享上网。不过，如 Worm.Bugbear.B （怪物II ）、Worm.Novarg.B （SCO 炸弹变种B ）等蠕虫病毒也会在本地系统监听1080 端口，给计算机的安全 带来不利。

　　操作建议：除了经常使用WinGate 来共享上网外，那么其他的建议关闭该端口。

　　1755 端口

　　端口说明：1755 端口默认情况下用于“Microsoft Media Server” （微软媒体服务器，简称MMS ），该协议是由微软发布的流媒体协议，通过MMS 协议可以在Internet 上实现Windows Media 服务器中流媒体文件的传送与播放。这些文件包括.asf 、.wmv 等，可以使用Windows Media Player 等媒体播放软件来实时播放。其中，具体来讲，1755 端口又可以分为TCP 和UDP 的MMS 协议，分别是MMST 和MMSU ，一般采用TCP 的MMS 协议，即MMST 。目前，流媒体和普通下载软件大部分都支持MMS 协议。

　　端口漏洞：目前从微软官方和用户使用MMS 协议传输、播放流媒体文件来看，并没有什么特别明显的漏洞，主要一个就是MMS 协议与防火墙和 NAT （网络地址转换）之间存在的兼容性问题。

　　操作建议：为了能实时播放、下载到MMS 协议的流媒体文件，建议开启该端口。

rtsp 和http 类似，属于应用层协议
通过socket rtsp 命令来进行通讯。
常用控制命令执行顺序常用的是5 个命令：

1 ，OPTIONS,// 询问server ，那些命令可用
2 ，DESCRIBE,// 请求rtsp 路径的媒体描述信息
3 ，SETUP,// 设置会话的属性，以及传输模式，建立会话

GET_PARAMETER,// 取得流控制参数，可能某些服务器不支持
SET_PARAMETER,// 设置流控制参数，可能某些服务器不支持

4 ，PLAY,// 开始播放流媒体数据
5 ，TEARDOWN // 关闭对话
————————————

ANNOUNCE, // 更新会话描述
PAUSE,// 临时停止流，而不释放服务器资源

client 有请求(request) ，server 就有应答(response)
一般控制命令基于tcp 协议。媒体数据传输使用udp 。

————————————
参考http ：和rtsp 在功能上有相似重叠的地方，RTSP 采用了HTTP/1.1 大多数的状态码，并且增加了RTSP 特定的状态码。

HTTP 协议定义了8 种可能的请求方法：
GET                 检索URI 中标识资源的一个简单请求
HEAD               与GET 方法相同，服务器只返回状态行和头标，并不返回请求文档
POST                服务器接受被写入客户端输出流中的数据的请求
PUT                 服务器保存请求数据作为指定URI 新内容的请求
DELETE            服务器删除URI 中命名的资源的请求
OPTIONS          关于服务器支持的请求方法信息的请求
TRACE             Web 服务器反馈Http 请求和其头标的请求
CONNECT        已文档化但当前未实现的一个方法，预留做隧道处理
————————————
rtsp 和http 的协议规范分别在RFC2326 和 RFC2616 有详细描述

mms 协议为微软的私有协议，未公开协议。采用私有自定义控制结构体来发送命令，而不是像http ，rtsp 协议采用发送文本命令控制

实时流协议RTSP(RealTimeStreamingProtocol) 是由RealNetworks 和Netscape 共同提出的，该协议定义了一 对多应用程序如何有效地通过IP 网络传送多媒体数据。RTSP 在体系结构上位于RTP 和RTCP 之上，它使用TCP 或RTP 完成数据传输。HTTP 与 RTSP 相比，HTTP 传送HTML ，而RTP 传送的是多媒体数据。HTTP 请求由客户机发出，服务器作出响应；使用RTSP 时，客户机和服务器都可以发 出请求，即RTSP 可以是双向的。