实时流协议rtsp.docx
《实时流协议rtsp.docx》由会员分享，可在线阅读，更多相关《实时流协议rtsp.docx（17页珍藏版）》请在冰豆网上搜索。
实时流协议rtsp
1.实时流协议RTSP
RTSP[3]协议以客户服务器方式工作，它是一个多媒体播放控制协议，用来使用户在播放从因特网下载的实时数据时能够进行控制，如：
暂停/继续、后退、前进等。
因此RTSP又称为“因特网录像机遥控协议”。
1.1.RTSP协议简介
要实现RTSP的控制功能，不仅要有协议，而且要有专门的媒体播放器（mediaplayer）和媒体服务器（mediaserver）。
媒体服务器与媒体播放器的关系是服务器与客户的关系。
媒体服务器与普通的万维网服务器的最大区别就是媒体服务器支持流式音频和视频的传送，因而在客户端的媒体播放器可以边下载边播放（需要先缓存一小段时间的节目）。
但从普通万维网服务器下载多媒体节目时，是先将整个文件下载完毕，然后再进行播放。
Forpersonaluseonlyinstudyandresearch;notforcommercialuse
图1RTSP与RTP和RTCP的关系
RTSP仅仅是使媒体播放器能控制多媒体流的传送。
因此，RTSP又称为带外协议，而多媒体流是使用RTP在带内传送的。
1.2.RTSP的报文结构
RTSP有两类报文：
请求报文和响应报文。
请求报文是指从客户向服务器发送请求报文，响应报文是指从服务器到客户的回答。
由于RTSP是面向正文的（text-oriented），因此在报文中的每一个字段都是一些ASCII码串，因而每个字段的长度都是不确定的。
RTSP报文由三部分组成，即开始行、首部行和实体主体。
在请求报文中，开始行就是请求行，RTSP请求报文的结构如图2所示。
图2RTSP请求报文的结构
RTSP请求报文的方法包括：
OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER和SET_PARAMETER。
RTSP请求报文的常用方法及作用如表1所示。
表1RTSP请求报文的常用方法及作用
方法
作用
OPTIONS
获得服务器提供的可用方法
DESCRIBE
得到会话描述信息
SETUP
客户端提醒服务器建立会话，并确定传输模式
TEARDOWN
客户端发起关闭请求
PLAY
客户端发送播放请求
响应报文的开始行是状态行，RTSP响应报文的结构如图3所示。
图3RTSP响应报文的结构
1.3.RTSP交互过程
C表示RTSP客户端，S表示RTSP服务端
①C->S:
OPTIONrequest//询问S有哪些方法可用
S->C:
OPTIONresponse//S回应信息中包括提供的所有可用方法
②C->S:
DESCRIBErequest//要求得到S提供的媒体初始化描述信息
S->C:
DESCRIBEresponse//S回应媒体初始化描述信息，主要是sdp
③C->S:
SETUPrequest//设置会话属性，以及传输模式，提醒S建立会话
S->C:
SETUPresponse//S建立会话，返回会话标识符及会话相关信息
④C->S:
PLAYrequest//C请求播放
S->C:
PLAYresponse//S回应请求信息
S->C:
发送流媒体数据
⑤C->S:
TEARDOWNrequest//C请求关闭会话
S->C:
TEARDOWNresponse//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支持帧级精度，允许远程数字编辑。
●演示描述中立：
协议未强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少需包含一个RTSPURI。
●代理与防火墙友好：
协议可由应用和传输层防火墙处理。
防火墙需要理解SETUP方法，为UDP媒体流打开一个“缺口”。
●适当的服务器控制：
如用户启动一个流，则也可以停止一个流。
●传输协调：
实际处理连续媒体流前，用户可协调传输方法。
●性能协调：
如基本特征无效，则必须有一些清理机制让用户决定那种方法不生效。
这允许用户提出适合自己的界面。
2．同其他协议的关系
RTSP在功能上与HTTP有重叠，最明显的交叉是在流媒体内容的发布上——大多是通过网页进行的。
目前的协议规范同时允许网页服务器和流媒体服务器支持RTSP实现。
例如，演示描述可通过HTTP或RTSP获取，这样减少了基于浏览器情况下的往返传递时间，同时也支持独立的RTSP服务器与不依赖HTTP的客户端通信。
但是，RTSP与HTTP的本质差别在于以下五个方面
●RTSP和HTTP是两个不同的协议，它们采用不同的方法和协议标志符。
●RTSP协议的数据发送不占用协议带宽，并且以不同的协议发送。
●HTTP是一个不对称协议，客户端发出请求，服务器应答。
在RTSP中，客户端和服务器都可发出请求，且请求是有状态的。
●HTTP是一个无状态协议，而RTSP在任何情况下，必须保持一定状态，以便在请求确认后的很长时间内，仍可设置参数，控制媒体流。
●RTSP使用ISO10646（UTF-8）定义，而不使用ISO8859-1定义，保持与当前的HTML一致。
虽然大多数实时媒体采用RTP作为传输协议，但RTSP并不绑定RTP。
重用HTTP的功能至少在两个方面有好处:
安全和代理。
由于要求非常接近，因此在缓存、代理和授权上采用HTTP功能是有价值的。
RTSP的实现
RTSP功能实现结构如下图所示。
RTSP在流媒体传输过程中，仅仅为双方建立连接，并不具备任何智能，也就不能很好地应付难以预料的网络状态。
因此，必须在它原有功能的基础上，进行改进。
1、初始化
在建立连接之前，客户端应向服务器提出测试请求，即要求服务器向客户端发送相应的测试数据包。
初始化的目的，是为了获取客户端和服务器之间的一些网络参数，估测基本网络状况，并以此选择相应的网络传输协议，使客户端获得最佳观看效果。
接到这个请求之后，服务器将根据自身情况进行如下测试：
●利用同客户端建立的RTSP通道，采用TCP协议，下发测试数据包。
●采用UDP协议，向客户端下发测试数据包。
测试数据包仅做测试用，上面带有相应的时间和顺序信息，其内部数据并无任何意义。
需要向RTSP增加一个新的方法TEST，以支持这种传输前的测试工作。
2、TCP传输
如果在TCP测试中，客户端反馈良好，即丢包率在可承受范围之内，并且在规定时间内到达，那么就认为客户端同服务器之间的网络状况良好，可以采用RTPoverTCP的方式发送数据。
由于TCP没有丢包（其自身具有重传机制），网络状况又属于良好，因此客户端将有较高的视听享受。
当子网内存在防火墙时，就需要采用RTSP附加数据传输方式。
即把音视频数据直接打包，在RTSP通信信道内传输。
这种传输方式也存在一定的问题：
●传输过程中，只是把音视频文件当成一个普通文件来处理，而没有考虑到它的音视频特性，不利于以后的扩展。
●音频与视频文件没有分离，不利于某些特殊需求的场合。
例如，客户端需要对音、视频做不同的处理。
●客户端的反馈和RTSP的控制信息也是通过同一条RTSP信道传送，因此控制效率不高。
因此，一般情况下，都默认使用RTPoverTCP的方式发送数据。
3、UDP传输
如果在TCP测试中，客户端的反馈存在比较大的问题，即网络情况不理想，就应该考虑进行UDP测试。
目前初步采取的措施，在服务器端准备了两种码率的视频文件——高码率和低码率。
收到客户端的TEST方法后，将采用UDP协议下发测试包。
采取的策略是每间隔2秒，下发一个1500字节的UDP数据包。
当丢包率处于一定范围（75％～85％）之内，就认为客户端的网络状况基本良好，可以下发高码率的电影文件;否则，认为测试不成功，由于网络状况的限制，仅对客户端下发低码率的电影文件。
在基于UDP的播放过程中，可能会出现轻微的马赛克，这是完全可以接受的。
这些马赛克出现的主要原因是：
●不可靠连接造成的网络丢包，为客户端被动丢包。
●高质量文件（DVD－>MP4）的高数据量，使得客户端解码线程和显示线程出现拥塞，从而出现客户端主动丢包。
但从整体而言，UDP传输消耗的带宽，要比TCP小许多。
在一般的视频点播要求下，使用基于UDP的传输线路，是完全可以满足要求的。
4、传输反馈
在传输过程中，主要采取的方式是RTPoverTCP或RTPoverUDP，因此，在RTP端口之外，还存在一个回传端口RTCP。
在服务器收到客户端的RTCP回传信息后，需要对其进行判断。
如果客户端的丢包率、解码率等指标在一定限度之下，就认为目前传送的视频文件可令客户端获得最大程度的音视频享受;否则，考虑改为传输更低码率的视频文件或放弃这次RTSP会话，以避免更大范围的拥塞。
5、实际效果
采取如上方法设计的系统，可以满足视频点播的基本要求，避免了服务器视频文件下发的盲目性，同时使客户端应用效果最好。
引入智能流技术
随着针对流媒体技术研究的不断深入，简单的流媒体实现已经不能满足人们日益增长的网络文化需求。
即使在宽带条件下，当网络用户达到一定限额时，简单的流媒体技术将面临着网络拥塞、丢包等常见的网络问题。
因此，如何在网络出现异常的情况下，依然保证客户端音视频享受的最大化，就成为现在研究的热点。
一种解决方法是服务器减少发送给客户端的数据而阻止再缓冲，在RealSystem5.0中，这种方法称为“视频流瘦化”。
这种方法的限制是RealVideo文件必须是一种数据速率设计，结果可通过抽取内部帧扩展到更低速率，导致质量较低，离原始数据速率越远，质量越差。
另一种解决方法是根据不同连接速率创建多个文件，根据用户连接，服务器发送相应文件，这种方法带来制作和管理上的困难，而且，用户连接是动态变化的，服务器也无法实时协调。
智能流技术通过两种途径克服带宽协调和流瘦化:
首先，确立一个编码框架，允许不同速率的多个流同时编码，合并到同一个文件中；第二，采用一种复杂客户/服务器机制探测带宽变化。
针对软件、设备和数据传输速度上的差别，用户以不同带宽浏览音视频内容。
为满足客户要求，RealNetworks公司编码、记录不同速率下媒体数据，并保存在单一文件中，此文件被称为智能流文件，即创建可扩展流式文件。
当客户端发出请求时，它将其带宽容量传给服务器，媒体服务器根据客户带宽将智能流文件相应部分传送给用户。
以此方式，用户可使用最优质的传输，制作人员只需要压缩一次，管理员也只需要维护单一文件，而媒体服务器根据所得带宽自动切换。
智能流通过描述Internet上变化的带宽特点来发送高质量媒体并保证其可靠性，并对混合连接环境的内容授权提供了解决方法。
这样流媒体实现方式如下：
对所有连接速率环境创建一个文件。
在混合环境下以不同速率传送媒体。
根据网络的变化情况，无缝切换到其他速率。
关键帧优先，音频比部分视频帧数据更重要，向后兼容老版本RealPlayer。
端口说明：
554端口默认情况下用于“RealTimeStreamingProtocol”（实时流协议，简称RTSP），该协议是由RealNetworks和Netscape共同提出的，通过RTSP协议可以借助于Internet将流媒体文件传送到RealPlayer中播放，并能有效地、最大限度地利用有限的网络带宽，传输的流媒体文件一般是Real服务器发布的，包括有.rm、.ram。
如今，很多的下载软件都支持RTSP协议，比如FlashGet、影音传送带等等。
端口漏洞：
目前，RTSP协议所发现的漏洞主要就是RealNetworks早期发布的HelixUniversalServer存在缓冲区溢出漏洞，相对来说，使用的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，通过该端口来实现局域网内计算机的共享上网。
不过，如，给计算机的安全带来不利。
操作建议：
除了经常使用WinGate来共享上网外，那么其他的建议关闭该端口。
1755端口
端口说明：
1755端口默认情况下用于“MicrosoftMediaServer”（微软媒体服务器，简称MMS），该协议是由微软发布的流媒体协议，通过MMS协议可以在Internet上实现WindowsMedia服务器中流媒体文件的传送与播放。
这些文件包括.asf、.wmv等，可以使用WindowsMediaPlayer等媒体播放软件来实时播放。
其中，具体来讲，1755端口又可以分为TCP和UDP的MMS协议，分别是MMST和MMSU，一般采用TCP的MMS协议，即MMST。
目前，流媒体和普通下载软件大部分都支持MMS协议。
端口漏洞：
目前从微软官方和用户使用MMS协议传输、播放流媒体文件来看，并没有什么特别明显的漏洞，主要一个就是MMS协议与防火墙和NAT（网络地址转换）之间存在的兼容性问题。
操作建议：
为了能实时播放、下载到MMS协议的流媒体文件，建议开启该端口。
rtsp和http类似，属于应用层协议通过socketrtsp命令来进行通讯。
常用控制命令执行顺序常用的是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关于服务器支持的请求方法信息的请求TRACEWeb服务器反馈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可以是双向的。
6.3RTSP协议实时流协议（RTSP）是应用级协议，控制实时数据的发送。
RTSP提供了一个可扩展框架，使实时数据，如音频与视频，的受控、点播成为可能。
数据源包括现场数据与存储在剪辑中数据。
该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。
6.3.1简介目的实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。
尽管连续媒体流与控制流交叉是可能的，通常它本身并不发送连续流。
换言之，RTSP充当多媒体服务器的网络远程控制。
RTSP连接没有绑定到传输层连接，如TCP。
在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可靠传输连接以发出RTSP请求。
此外，可使用无连接传输协议，如UDP。
RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。
实时流协议在语法和操作上与HTTP/1.1类似，因此HTTP的扩展机制大都可加入RTSP。
协议支持的操作如下：
从媒体服务器上检索媒体：
用户可通过HTTP或其它方法提交一个演示描述。
如演示是组播，演示式就包含用于连续媒体的的组播地址和端口。
如演示仅通过单播发送给用户，用户为了安全应提供目的地址。
媒体服务器邀请进入会议：
媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。
这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。
将媒体加到现成讲座中：
如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。
如HTTP/1.1中类似，RTSP请求可由代理、通道与缓存处理。
协议特点RTSP特性如下：
可扩展性：
新方法和参数很容易加入RTSP。
易解析：
RTSP可由标准HTTP或MIME解吸器解析。
安全：
RTSP使用网页安全机制。
独立于传输：
RTSP可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，可使用可靠流协议。
多服务器支持：
每个流可放在不同服务器上，用户端自动同不同服务器建立几个并发控制连接，媒体同步在传输层执行。
记录设备控制：
协议可控制记录和回放设备。
流控与会议开始分离：
仅要求会议初始化协议提供，或可用来创建唯一会议标识号。
特殊情况下，SIP或H.323可用来邀请服务器入会。
适合专业应用：
通过SMPTE时标，RTSP支持帧级精度，允许远程数字编辑演示描述中立：
协议没强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少必须包含一个RTSPURI。
代理与防火墙友好：
协议可由应用和传输层防火墙处理。
防火墙需要理解SETUP方法，为UDP媒体流打开一个"缺口"。
HTTP友好：
此处，RTSP明智的采用HTTP观念，使现在结构都可重用。
结构包括Internet内容选择平台（PICS）。
由于在大多数情况下控制连续媒体需要服务器状态，RTSP不仅仅向HTTP添加方法。
适当的服务器控制：
如用户启动一个流，他必须也可以停止一个流。
传输协调；实际处理连续媒体流前，用户可协调传输方法。
性能协调：
如基本特征无效，必须有一些清理机制让用户决定那种方法没生效。
这允许用户提出适合的用户界面。
由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同请求集。
RTSP可以如下三种方式扩展，这里以改变大小排序：
以新参数扩展。
如用户需要拒绝通知，而方法扩展不支持，相应标记就加入要求的段中。
加入新方法。
如信息接收者不理解请求，返回501错误代码（还未实现），发送者不应再次尝试这种方法。
用户可使用OPTIONS方法查询服务器支持的方法。
服务器使用公共响应头列出支持的方法。
定义新版本协议，允许改变所有部分。
（除了协议版本号位置）每个演示和媒体流可用RTSPURL识别。
演示组成的整个演示与媒体属性由演示描述文件定义。
使用HTTP或其它途径用户可获得这个文件，它没有必要保存在媒体服务器上。
为了说明，假设演示描述描述了多个演示，其中每个演示维持了一个公共时间轴。
为简化说明，且不失一般性，假定演示描述的确包含这样一个演示。
演示可包含多个媒体流。
除媒体参数外，网络目标地址和端口也需要决定。
下面区分几种操作模式：
单播：
以用户选择的端口号将媒体发送到RTSP请求源。
组播，服务器选择地址：
媒体服务器选择组播地址和端口，这是现场直播或准点播常用的方式。
组播，用户选择地址：
如服务器加入正在进行的组播会议，组播地址、端口和密匙由会议描述给出。
RTSP状态RTSP控制通过单独协议发送的流，与控制通道无关。
例如，RTSP控制可通过TCP连接，而数据流通过UDP。
因此，即使媒体服务器没有收到请求，数据也会继续发送。
在连接生命期，单个媒体流可通过不同TCP连接顺序发出请求来控制。
所以，服务器需要维持能联系流与RTSP请求的连接状态。
RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的作用：
SETUP：
让服务器给流分配资源，启动RTSP连接。
PLAY与RECORD：
启动SETUP分配流的数据传输。
PAUSE：
临时停止流，而不释放服务器资源。
TEARDOWN：
释放流的资源，RTSP连接停止。
标识状态的RTSP方法使用连接头段识别RTSP连接，为响应SETUP请求，服务器连接产生连接标识。
与其他协议关系RTSP在功能上与HTTP有重叠，与HTTP相互作用体现在与流内容的初始接触是通过网页的。
目前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。
例如，演示描述可通过HTTP和RTSP检索，这降低了浏览器的往返传递，也允许独立RTSP服务器与用户不全依靠HTTP。
但是，RTSP与HTTP的本质差别在
升级会员 