网站建设学生选课课程设计报告,郴州seo外包,网站服务器有什么用,电脑自助建站1. 实 时流协议RTSP
RTSP[3]协 议以客户服务器方式工作#xff0c;它是一个多媒体播放控制协议#xff0c;用来使用户在播放从因特网下载的实时数据时能够进行控制#xff0c;如#xff1a;暂停/继 续、后退、前进等。因此 RTSP 又称为“因特网录像机遥控协议”。
1.1. …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 10646UTF-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数据 包。当丢包率处于一定范围7585之内就认为客户端的网络状况基本良好可以下发高码率的电影文件;否则认为测试不成功由于网络状况的限 制仅对客户端下发低码率的电影文件。 在基于UDP的播放过程中可能会出现轻微的马赛克这是完全可以接受的。这些马赛克出现的主要原因是 ● 不可靠连接造成的网络丢包为客户端被动丢包。 ● 高质量文件DVDMP4的高数据量使得客户端解码线程和显示线程出现拥塞从而出现客户端主动丢包。 但从整体而言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”保留。之前我们曾经提到过动态端口的范围是从 102465535而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.BSCO炸弹变种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个命令 1OPTIONS,//询问server那些命令可用 2DESCRIBE,//请求rtsp路径的媒体描述信息 3SETUP,//设置会话的属性以及传输模式建立会话 GET_PARAMETER,//取得流控制参数可能某些服务器不支持 SET_PARAMETER,//设置流控制参数可能某些服务器不支持 4PLAY,//开始播放流媒体数据 5TEARDOWN //关闭对话 ———————————— 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协议为微软的私有协议未公开协议。采用私有自定义控制结构体来发送命令而不是像httprtsp协议采用发送文本命令控制 实时流协议RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的该协议定义了一 对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上它使用TCP或RTP完成数据传输。HTTP与 RTSP相比HTTP传送HTML而RTP传送的是多媒体数据。HTTP请求由客户机发出服务器作出响应使用RTSP时客户机和服务器都可以发 出请求即RTSP可以是双向的。 6.3 RTSP协议 实时流协议RTSP是应用级协议控制实时数据的发送。RTSP提供了一个可扩展框架使实时数据如音频与视频的受控、点播成为可能。数据源包括 现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接为选择发送通道如UDP、组播UDP与TCP提供途径并为选择基于RTP上发送 机制提供方法。 6.3.1 简介 6.3.1.1 目的 实时流协议RTSP建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交叉是可能的通常它本身并不发送连续流。换言之RTSP充 当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接如TCP。在RTSP连接期间RTSP用户可打开或关闭多个对服务器的可靠传输连接 以发出RTSP 请求。此外可使用无连接传输协议如UDP。RTSP流控制的流可能用到RTP但RTSP操作并不依赖用于携带连续媒体的传输机制。实时流协议在语法 和操作上与HTTP/1.1类似因此HTTP的扩展机制大都可加入RTSP。协议支持的操作如下 从媒体服务器上检索媒体 用户可通过HTTP或其它方法提交一个演示描述。如演示是组播演示式就包含用于连续媒体的的组播地址和端口。如演示仅通过单播发送给用户用户为了安全 应提供目的地址。 媒体服务器邀请进入会议 媒体服务器可被邀请参加正进行的会议或回放媒体或记录其中一部分或全部。这种模式在分布式教育应用上很有用会议中几方可轮流按远程控制按钮。 将媒体加到现成讲座中 如服务器告诉用户可获得附加媒体内容对现场讲座显得尤其有用。如HTTP/1.1中类似RTSP请求可由代理、通道与缓存处理。 6.3.1.2 协议特点 RTSP 特性如下 可扩展性 新方法和参数很容易加入RTSP。 易解析 RTSP可由标准 HTTP或MIME解吸器解析。 安全 RTSP使用网页安全机制。 独立于传输 RTSP可使用不可靠数据报协议UDP、可靠数据报协议RDP如要实现应用级可靠可使用可靠流协议。 多服务器支持 每个流可放在不同服务器上用户端自动同不同服务器建立几个并发控制连接媒体同步在传输层执行。 记录设备控制 协议可控制记录和回放设备。 流控与会议开始分离 仅要求会议初始化协议提供或可用来创建唯一会议标识号。特殊情况下 SIP或H.323 可用来邀请服务器入会。 适合专业应用 通过SMPTE 时标RTSP支持帧级精度允许远程数字编辑 演示描述中立 协议没强加特殊演示或元文件可传送所用格式类型然而演示描述至少必须包含一个RTSP URI。 代理与防火墙友好 协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法为UDP媒体流打开一个缺口。 HTTP友好 此处RTSP明智的采用HTTP观念使现在结构都可重用。结构包括Internet 内容选择平台PICS。由于在大多数情况下控制连续媒体需要服务器状态 RTSP不仅仅向HTTP 添加方法。 适当的服务器控制 如用户启动一个流他必须也可以停止一个流。 传输协调 实际处理连续媒体流前用户 可协调传输方法。 性能协调 如基本特征无效必须有一些清理机制让用户决定那种方法没生效。这允许用户提出适合的用户界面。 6.3.1.3扩展RTSP 由于不是所有媒体服务器有着相同的功能媒体服务器有必要支持不同请求集。RTSP 可以如下三种方式扩展这里以改变大小排序 以新参数扩展。如用户需要拒绝通知而方法扩展不支持相应标记就加入要求的段中。 加入新方法。如信息接收者不理解请求返回501错误代码还未实现发送者不应再次尝试这种方法。用户可使用OPTIONS方法查询服务器支持的方 法。服务器使用公共响应头列出支持的方法。 定义新版本协议允许改变所有部分。除了协议版本号位置 6.3.1.4操作模式 每个演示和媒体流可用RTSP URL识别。演示组成的整个演示与媒体属性由演示描述文件定义。使用HTTP或其它途径用户可获得这个文件它没有必要保存在媒体服务器上。 为了说明假设演示描述描述了多个演示其中每个演示维持了一个公共时间轴。为简化说明且不失一般性假定演示描述的确包含这样一个演示。演示可包含多 个媒体流。除媒体参数外网络目标地址和端口也需要决定。下面区分几种操作模式 单播 以用户选择的端口号将媒体发送到RTSP请求源。 组播服务器选择地址 媒体服务器选择组播地址和端口这是现场直播或准点播常用的方式。 组播用户选择地址 如服务器加入正在进行的组播会议组播地址、端口和密匙由会议描述给出。 6.3.1.5 RTSP状态 RTSP控制通过单独协议发送的流与控制通道无关。例如RTSP控制可通过TCP连接而数据流通过UDP。因此即使媒体服务器没有收到请求数据 也会继续发送。在连接生命期单个媒体流可通过不同TCP连接顺序发出请求来控制。所以服务器需要维持能联系流与RTSP请求的连接状态。RTSP中很 多方法与状态无关但下列方法在定义服务器流资源的分配与应用上起着重要的作用 SETUP 让服务器给流分配资源启动RTSP连接。 PLAY与RECORD 启动SETUP 分配流的数据传输。 PAUSE 临时停止流而不释放服务器资源。 TEARDOWN 释放流的资源RTSP连接停止。 标识状态的RTSP方法使用连接头段识别RTSP连接为响应SETUP请求服务器连 接产生连接标识。 6.3.1.6 与其他协议关系 RTSP在功能上与HTTP有重叠与HTTP相互作用体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许在网页服务器与实现RTSP媒 体服务器之间存在不同传递点。例如演示描述可通过HTTP和RTSP检索这降低了浏览器的往返传递也允许独立RTSP 服务器与用户不全依靠HTTP。 但是RTSP与HTTP 的本质差别在于数据发送以不同协议进行。HTTP是不对称协议用户发出请求服务器作出响应。RTSP中媒体用户和服务器都可发出请求且其请求都是 无状态的在请求确认后很长时间内仍可设置参数控制媒体流。重用HTTP功能至少在两个方面有好处即安全和代理。要求非常接近在缓存、代理和授权 上采用HTTP功能是有价值的。 当大多数实时媒体使用RTP作为传输协议时RTSP没有绑定到RTP。RTSP假设存在演示描述格式可表示包含几个媒体流的演示的静态与临时属性。 6.3.2 协议参数 6.3.3 RTSP 信息 RTSP是基于文本的协议采用ISO 10646 字符集使用UTF-8编码方案。行以CRLF中断但接收者本身可将CR和LF解释成行终止符。基于文本的协议使以自描述方式增加可选参数更容易。由于 参数的数量和命令的频率出现较低处理效率没引起注意。如仔细研究文本协议很容易以脚本语言如Tcl、Visual Basic与Perl实现研究原型。 10646字符集避免敏感字符集切换但对应用来说不可见。RTCP也采用这种编码方案。带有重要意义位的ISO 8859-1字符表示如100001x 10xxxxxx.。RTSP信息可通过任何低层传输协议携带。 请求包括方法、方法作用于其上的对象和进一步描述方法的参数。方法也可设计为在服务器端只需要少量或不需要状态维护。当信息体包含在信息中信息体长度有 如下因素决定 不管实体头段是否出现在信息中不包括信息体的的响应信息总以头段后第一和空行结束。 如出现内容长度头段其值以字节计表示信息体长度。如未出现头段其值为零。 服务器关闭连接。 注意RTSP目前并不支持HTTP/1.1块传输编码需要有内容长度头。假如返回适度演示描述长度即使动态产生使块传输编码没有必要服务器 也应该能决定其长度。如有实体即使必须有内容长度且长度没显式给出规则可确保行为合理。 从用户到服务器端的请求信息在第一行内包括源采用的方法、源标识和所用协议版本。RTSP定义了附加状态代码而没有定义任何HTTP代码。 6.3.4 实体 如不受请求方法或响应状态编码限制请求和响应信息可传输实体实体由实体头文件和试题体组成有些响应仅包括实体头。在此根据谁发送实体、谁接收实 体发送者和接收者可分别指用户和服务器。 实体头定义实体体可选元信息如没有实体体指请求标识的资源。扩展头机制允许定义附加实体头段而不用改变协议但这些段不能假定接收者能识别。不可识 别头段应被接收者忽略而让代理转发。 6.3.5 连接 RTSP请求可以几种不同方式传送 1、持久传输连接用于多个请求/响应传输。 2、每个请求/响应传输一个连接。 3、无连接模式。 传输连接类型由RTSP URI来定义。对 rtsp 方案需要持续连接而rtspu方案调用RTSP 请求发送而不用建立连接。 不象HTTPRTSP允许媒体服务器给媒体用户发送请求。然而这仅在持久连接时才支持否则媒体服务器没有可靠途径到达用户这也是请求通过防火墙从 媒体服务器传到用户的唯一途径。 6.3.6 方法定义 方法记号表示资源上执行的方法它区分大小写。新方法可在将来定义但不能以$开头。 某些防火墙设计与其他环境可能要求服务器插入RTSP方法和流数据。由于插入将使客户端和服务器操作复杂并强加附加开销除非有必要应避免这样做。插 入二进制数据仅在RTSP通过TCP传输时才可使用。流数据如RTP包用一个ASCII美圆符号封装后跟一个一字节通道标识其后是封装二进制数据 的长度两字节整数。流数据紧跟其后没有CRLF但包括高层协议头。每个$块包含一个高层协议数据单元。 当传输选择为RTPRTCP信息也被服务器通过TCP连接插入。缺省情况下RTCP包在比RTP通道高的第一个可用通道上发送。客户端可能在另一通道 显式请求RTCP包 这可通过指定传输头插入参数中的两个通道来做到。当两个或更多流交叉时为取得同步需要RTCP。而且这为当网络设置需要通过TCP控制连接透过 RTP/RTCP提供了一条方便的途径可能时在UDP上进行传输。 6.3.7 流水线操作 支持持久连接或无连接的客户端可能给其请求排队。服务器必须以收到请求的同样顺序发出响应。如果请求不是发送给组播组接收者就确认请求如没有确认信 息发送者可在超过一个来回时间RTT后重发同一信息。 RTT在TCP中估计初始值为500 ms。应用缓存最后所测量的RTT作为将来连接的初始值。如使用一个可靠传输协议传输RTSP请求不允许重发RTSP应用反过来依赖低层传输提供可 靠性。如两个低层可靠传输如TCP 和RTSP应用重发请求有可能每个包损失导致两次重传。由于传输栈在第一次尝试到达接收着者前不会发送应用层重传接收者也不能充分利用应用层重传。 如包损失由阻塞引起不同层的重发将使阻塞进一步恶化。时标头用来避免重发模糊性问题避免对圆锥算法的依赖。每个请求在CSeq头中携带一个系列号每 发送一个不同请求它就加一。如由于没有确认而重发请求请求必须携带初始系列号。 实现RTSP的系统必须支持通过TCP传输RTSP 并支持UDP。对UDP和TCPRTSP服务器的缺省端口都是554。许多目的一致的RTSP包被打包成单个低层PDU或TCP流。RTSP数据可与 RTP和RTCP包交叉。不象HTTPRTSP信息必须包含一个内容长度头无论信息何时包含负载。否则RTSP包以空行结束后跟最后一个信息头。
