嗅探器的设计与实现

1、 目录1、 问题背景概述二、协议分析说明分析 2.1 RTSP 总结2.2 MMS总结2.3 RTSP总结三、技术综述报告四、前景展望1、 问题背景概述 流媒体指在Internet/Intranet中使用流式传输技术的连续时基媒体，如：音频、视频或多媒体文件。流式媒体在播放前并不下载整个文件，只将开始部分内容存入内存，流式媒体的数据流随时传送随时播放，只是在开始时有一些延迟。流媒体实现的关键技术就是流式传输。 常见的流媒体协议有以下几种：1、RTMP（RealTime Messaging Protocol），这是Adobe公司开发的流媒体传输协议，使用Flash Media Server来搭建

2、。2、MMS（Media Server Protocol,MMS），这是微软定义的一种流媒体传输协议，可使用WIndows Media Server搭建。3、即时串流通讯协议（Real Time Streaming Protocol，RTSP），它是RealNetworks公司协助建立的一个用来传送串流媒体的开放网页标准，使用RealServer服务器搭建环境。二、协议分析说明分析 2.1RTSP 总结 Real Time .1 RMessaging Protocol（实时消息传送协议协议)概述实时消息传送协议是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开

3、发的私有协议。它有三种变种：1)工作在TCP之上的明文协议，使用端口1935；2)RTMPT封装在HTTP请求之中，可穿越防火墙；3)RTMPS类似RTMPT，但使用的是HTTPS连接；介绍:RTMP协议是被Flash用于对象,视频,音频的传输.该协议建立在TCP协议或者轮询HTTP协议之上.RTMP协议就像一个用来装数据包的容器,这些数据可以是AMF格式的数据,也可以是FLV中的视/音频数据.一个单一的连接可以通过不同的通道传输多路网络流.这些通道中的包都是按照固定大小的包传输的. 下面的文档详细说明了RTMP 消息块流。它位高层多媒体流协议提供多路技术和包服务RTMP 消息块流是为RTMP

4、 协议设计的。他可以处理任何传送消息流的协议。每一个消息包含时间戳合有效负载类型标示。RTMP 消息块流和RTMP 一起适用于多样性音视频应用程序，从一对一和一对多向视频点播服务器直接广播到交互式会议应用程序。 当用到实时传输协议就像TCP，RTMP 消息块流提供可靠地规则时间戳的端到端全信息传送。穿过多层流，RTMP 消息块流不提供任何控制的优先级别和相似形式，但是可以用于高层协议提供这样的优先级。例如，一段实时视频服务会选择丢弃给于缓慢的客户的视频信息确保音频信息可以及时被接收。RTMP 消息块流包含它自己的入队协议控制消息，也提供一个高层协议机制用于嵌入用户的控制消息。2. 定义 有效负

5、载 包含在包中的数据，就像音频样本或者压缩的视频数据。 包： 一个数据包由固定的包头和有效负载数据组成，一些底层协议或许需要包的封装来被定义 端口： 在TCP/P 协议中定义的用正整数表示的端口号用于在传输中提取以区分目标主机的不同应用于OSI 传输层的传输选择。TSEL就是端口。 传输地址： 网络地址和端口的组合识别一个传输层终端端口。例如一个IP 地址和TCP 端口。数据包从一个源传：输层地址传送到目标段的传输层地址。 消息流：一个通信的逻辑通道，允许消息流通。 消息流ID：􀈍每一个消息拥有一个分配的ID 识别跟随的消息流。 消息快：消息的片段，消息被分成小的部分。在他们

6、在网络中发送之前交叉存储。消息块确保定制时间戳的端到端全消息传送穿过多层流。 消息块流：一个通信的逻辑通道允许消息块在一个特定的方向上流通，消息块流可以从客户端传送到服务器也可以相反。 消息块流ID:每一个消息块有一个分配的ID 用于识别更随的消息块流。 复合技术:把分开的音视频数据组合成一条音视频流的过程，使同时传送许多音视频数据成为可能。 逆复合技术:复合的反向过程交叉存取组装的音频视频数据，使他们成为最初的音视频数据3􀈅 字节顺序，列队和时间格式所有的整数字段有被网络字节负载着，字节0 是第一个显示出来的.也是一段文字和字段中最重要的。这种字节顺序一般被认为“大字节”.

7、数字常量在这种文档里是用十进制表示。 所有RTMP 消息块流是以用字节列队，例如，一个16 字节的字段也许会在字数字节的偏移段。那里要填充被标示.填充字节应该有0 值。 在RTMP 消息块流中的时间戳用整数表示，单位为毫秒。每一个消息块流以时间戳0 开始但是这不是必须的，只要两个终端在时间点上达成一致，注意那就意味着任何穿过多消息块流异步传输(特别是分散的主机).在RTMP 消息块流之外需要一些而外的机制。 时间戳必须始终在线性的增加，允许应用程序处理异步传输，带宽度量，检测和流控制。 因为时间戳一般是只有32 字节的长度，他们周期小于50 天，因为六流是允许不停地流动的，最终可以运行几年。一

8、个RTMP 消息块流应用必须用到模运算用于相减和比较，任何合理的方式都可以被接受，只要两端都达成一致。一个应用可以假设，例如，所有相近的时间戳在2 的31 次方以内。所以10000 在4000000000 后面.3000000000 在4000000000 前面。 时间戳delta 作为一个表示毫秒的无符号整数也会被详细介绍，和先前的时间戳相比，时间戳delta 可以是24 字节或者是32 字节的长度4。􀈅 消息格式： 一个消息的格式可以分裂成消息块以支持复用，依靠高层协议，消息格式应该包含创造消息块的必须字段。 时间戳： 消息的时间戳，这个字段可以传输4 个字节。 长度：

9、消息的有效负载的长度，如果消息头不能被省略，他应该包含在长度中，这个字段在消息块包头中占有3 个字节。 类型ID：􀈍 协议控制消息的类型字段的范围是被保留的，这些传播信息的消息被RTMP 消息块和高层协议处理。所有其他的类型ID 可被高层协议使用，被RTMP 消息块当做不透明的值事实上在RTMP 消息块中需要这些值当做类型的是没有的，所有的消息可以成为通一种类型。或者应用程序用这个字段区分同步迹象而不是类型，这个字段占用1 个字节。 消息流ID: 消息流ID 可以是任意值，不同的消息复合依靠的同样的消息块流是基于他们的消息流ID 被逆复合而成的，在此之上，直到RTMP 消息块

10、被关注，这是一个不透明的值，这个字段在包头中占用4 个字节。5􀈅 握手 一个RTMP 通信以握手开始，握手不像其他的协议，他包含三个固定长度的消息块。客户（初始化通信的终端）和服务器每放发送同样的三个消息块，说明一下，被客户段发送的消息块被指定为C0，C1，C2，被服务器端发送的消息被指定为S0，S1，S2。2.2 MMS总结 MMS (Microsoft Media Server Protocol)，中文“微软媒体服务器协议”，用来访问并流式接收 Windows Media 服务器中 .asf 文件的一种协议。MMS 协议用于访问 Windows Media 发布点上的单播

11、内容。MMS 是连接 Windows Media 单播服务的默认方法。若观众在 Windows Media Player 中键入一个 URL 以连接内容，而不是通过超级链接访问内容，则他们必须使用MMS 协议引用该流。MMS的预设埠（端口）是1755。 当使用 MMS 协议连接到发布点时，使用协议翻转以获得最佳连接。“协议翻转”始于试图通过 MMSU 连接客户端。 MMSU 是 MMS 协议结合 UDP 数据传送。如果 MMSU 连接不成功，则服务器试图使用 MMST。MMST 是 MMS 协议结合 TCP 数据传送。 如果连接到编入索引的 .asf 文件，想要快进、后退、暂停、开始和停止流，

12、则必须使用 MMS。不能用 UNC 路径快进或后退。若您从独立的 Windows Media Player 连接到发布点，则必须指定单播内容的 URL。若内容在主发布点点播发布，则 URL 由服务器名和 .asf 文件名组成。例如：mms:/windows_media_server/sample.asf。其中 windows_media_server 是 Windows Media 服务器名，sample.asf 是您想要使之转化为流的 .asf 文件名。 若您有实时内容要通过广播单播发布，则该 URL 由服务器名和发布点别名组成。例如：mms:/windows_media_server/Li

13、veEvents。这里 windows_media_server 是 Windows Media 服务器名，而 LiveEvents 是发布点名。 MMS是Multimedia Messaging Service的缩写，中文译为多媒体信息服务，也称“彩信”，是按照3GPP的标准也是WAP论坛的标准有关多媒体信息的标准开发的最新业务，它最大的特色就是支持多媒体功能，可以在GPRS、CDMA 1X、3G、EDGE的支持下，以WAP无线应用协议为载体传送视频短片、图片、声音和文字，传送方式除了在手机间传送外，还可以是手机与电脑之间的传送。具有MMS功能的移动电话的独特之处在于其内置的媒体编辑器，使用

14、户可以很方便地编写多媒体信息。如果手机具有一个内置或外置的照相机，用户便可以制作出PowerPoint格式的信息或电子明信片，并把他们传送给朋友或同事。目前，这一应用服务已逐渐走向成熟，成为主流的短信格式。2.3 RTSP总结 RTSP（Real Time Streaming Protocol），实时流传输协议，是TCP/IP协议体系中的一个应用层协议，由哥伦比亚大学、网景和RealNetworks公司提交的IETF RFC标准。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。HTTP与RTSP相比

15、，HTTP传送HTML，而RTSP传送的是多媒体数据。HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。 概念RTSP是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网 RTSP络延迟。而前面提到的允许同时多个串流需求控制（Multicast），除了可以降低服务器端的网络用量，更进而支持多方视讯会议（Video Conference）。因为与

16、HTTP1.1的运作方式相似，所以代理服务器Proxy的快取功能Cache也同样适用于RTSP，并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。 简介该协议用于C/S模型，是一个基于文本的协议，用于在客户端和服务器端建立和协商实时流会话。 实时流协议（RTSP）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方

17、法。 实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交换是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可传输连接以发出RTSP请求。此外，可使用无连接传输协议，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。 协议支持的操作如下： (1）从媒体服务器上检索媒体：用户可通过HTTP或其它方法提交一个演示描述。如演示是组播，演示式就包含用于连续媒体的的组播地址和端口。如演示仅

18、通过单播发送给用户，用户为了安全应提供目的地址。 (2）媒体服务器邀请进入会议：媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。 (3）将媒体加到现成讲座中：如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。如HTTP/1.1中类似，RTSP请求可由代理、通道与缓存处理。 协议特点(1) 可扩展性：新方法和参数很容易加入RTSP。 (2) 易解析：RTSP可由标准HTTP或MIME解析器解析。 (3) 安全：RTSP使用网页安全机制。 (4) 独立于传输：RTSP可使用不可靠数据报协议（EDP

19、）、可靠数据报协议（RDP）；如要实现应用级可靠，可使用可靠流协议。 (5) 多服务器支持：每个流可放在不同服务器上，用户端自动与不同服务器建立几个并发控制连接，媒体同步在传输层执行。 (6) 记录设备控制：协议可控制记录和回放设备。 (7) 流控与会议开始分离：仅要求会议初始化协议提供，或可用来创建惟一会议标识号。特殊情况下，可用SIP或H.323来邀请服务器入会。 (8) 适合专业应用：通过SMPTE时标，RTSP支持帧级精度，允许远程数字编辑。 (9) 演示描述中立：协议没强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少必须包括一个RTSP URL。 (10) 代理与防火墙友

20、好：协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个“缺口”。 (11) HTTP友好：此处，RTSP明智地采用HTTP观念，使现在结构都可重用。结构包括Internet内容选择平台（PICS）。由于在大多数情况下控制连续媒体需要服务器状态，RTSP不仅仅向HTFP添加方法。 (12) 适当的服务器控制：如用户启动一个流，必须也可以停止一个流。 (13) 传输协调：实际处理连续媒体流前，用户可协调传输方法。 (14) 性能协调：如基本特征无效，必须有一些清理机制让用户决定哪种方法没生效。这允许用户提出适合的用户界面。 协议结构RTSP是一种文本协议，采用UT

21、F-8编码中的ISO 10646字符集。一行可通过CRLF终止，但接收端需要做好解释CR和LF作为一行终止符的准备。关于头字段概述如下： Header Type Support Methods Accept R opt. entity Accept-EncodingR opt. entity Accept-Language R opt. all AllowR opt. all Authorization R opt. all Bandwidth R opt. all Blocksize R opt. All but OPTIONS,TEARDOWN Cache-Control G opt. S

22、ETUP Conference R opt. SETUP Connection G req. all Content-Base E opt. entity Content-Encoding E req. SET_PARAMETER Content-Encoding Ereq. DESCRIBE,ANNOUNCE Content-Language E req. DESCRIBE,ANNOUNCE Content-Length Ereq. SET_PARAMETER,ANNOUNCE Content-Length E req. entity Content-Location E opt. enti

23、ty Content-Type E req. SET_PARAMETER,ANNOUNCE Content-Type R req. entity CSeq G req. all Date G opt. all Expires E opt. DESCRIBE,ANNOUNCE From R opt. all If-Modified-Since R opt. DESCRIBE,SETUP Last-Modified E opt. entity Proxy-Authenticate Proxy-Require R req. all Public R opt. all Range R opt. PLA

24、Y,PAUSE,RECORD Range R opt. PLAY,PAUSE,RECORD Referer R opt. all Require R req. all Retry-After R opt. all RTP-Info R req. PLAY Scale Rr opt. PLAY,RECORD SessionRr req. All but SETUP,OPTIONS Server R opt. all Speed Rr opt. PLAY Transport Rr req. SETUP UnsupportedR req. all User-AgentR opt. all ViaG

25、opt. all WWW-AuthenticateR opt. all 类型"g"表示请求和响应中的通用请求头；类型“R”表示请求头；类型“r”表示响应头；类型"e"表示实体头字段。在“support”一栏中标有“req.”的字段必须由接收者以特殊的方法实现；而“opt.”的字段是可选的。注意，不是所有“req.”字段在该类型的每个请求中都会被发送。“req.”只表示客户机（支持响应头）和服务器（支持请求头）必须执行该字段。最后一栏列出了关于头字段产生作用的方法；其中“entity”针对于返回一个信息主体的所有方法。 协议参数1RTSP版本 H.321采

26、用，用RTSP代替HTTP。 2RTSPURL “rksp"和“rtspu"方案用于指RTSP协议使用的网络资源，为RTSP URL定义方案特定的语法和语义。 3会议标识 会议标识对RTSP来说是模糊的，采用标准URI编码方法编码，可包含任何八位组数值。会议标识必须全局惟一。 4连接标识 连接标识是长度不确定的字符串，必须随机选择，至少要8个八位组长，使其很难被猜出。 5SMPTE相关时标 SMPTE相关时标表示相对剪辑开始的时间，相关时标表示成SMPTE时间代码，精确到帧级。时间代码格式为小时：分钟：秒：帧。缺省smpte格式是"SMPTE 30"，帧

27、速率为每秒29.97帧。其他SMPTE代码可选择使用smpte时间获得支持（如"SMPIE 25")。时间数值中帧段值可从0到29。每秒30与29.97帧的差别可将每分钟的头两帧丢掉来实现。如帧值为零，就可删除。 6正常播放时间 正常播放时间（NPT）表示相对演示开始的流绝对位置。时标由十进制分数组成。左边部分用秒或小时、分钟、秒表示；小数点右边部分表示秒的部分。演示的开始对应0.0秒，负数没有定义。特殊常数定义成现场事件的当前时刻，这也许只用于现场事件。直观上，NPT是联系观看者与程序的时钟，通常以数字式显示在VCR上。 7绝对时间 绝对时间表示成ISO 8601时标，采

28、用UTC(GMT）。 8可选标签 可选标签是用于指定RTSP新可选项的惟一标记。这些标记用在请求和代理-请求头段。当登记新RTSP选项时，需提供下列信息： （1）名称和描述选项。名称长度不限，但不应该多于20个字符。名称不能包括空格、控制字符。 （2）表明谁改变选项的控制。如IETF，ISO，ITU-T，或其他国际标准团体、联盟或公司。 （3）深入描述的参考，如RFC、论文、专利、技术报告、文档源码和计算机手册。 （4）对专用选项，附上联系方式。 RTSP信息RTSP是基于文本的协议，采用ISO 10646字符集，使用UTF-8编码方案。行以CRLF中断，但接收者本身可将CR和LF解释成行终止

29、符。基于文本的协议使以自描述方式增加可选参数更容易。由于参数的数量和命令的频率出现较低，处理效率没引起注意。文本协议很容易以脚本语言（如：Tcl，Visual Basic与Perl）实现研究原型。 ISO 10646字符集避免敏感字符集切换，但对应用来说不可见。RTCP也采用这种编码方案。带有重要意义位的ISO 8859-1字符表示如100001x 10x x x x x x。RTSP信息可通过任何低层传输协议携带。 请求包括方法、方法作用于其上的对象以及进一步描述方法的参数。方法也可设计为在服务器端只需要少量或不需要状态维护。当信息体包含在信息中，信息体长度由如下因素决定： (1）不管实体头

30、段是否出现在信息中，不包括信息体的响应，信息总以头段后第一个空行结束。 (2）如出现内容长度头段，其值以字节计，表示信息体长度。如未出现头段，其值为零。 (3）服务器关闭连接。 注意，RTSP目前并不支持HTTP 1.1“块”传输编码，需要有内容长度头。假如返回适度演示描述长度，即使动态产生，使块传输编码没有必要，服务器也应该能决定其长度。如有实体，即使必须有内容长度，且长度没显式给出，规则可确保行为合理。 从用户到服务器端的请求信息在第一行内包括源采用的方法、源标识和所用协议版本。RTSP定义了附加状态代码，但没有定义任何HTTP代码。 RTSP实体如不受请求方法或响应状态编码限制，请求和响

31、应信息可传输实体，实体则由实体头文件和实体体组成，有些响应仅包括实体头。在此，根据谁发送实体、谁接收实体，发送者和接收者可分别指用户和服务器。 实体头定义实体体可选元信息，如没有实体体，指请求标识的资源。扩展头机制允许定义附加实体头段，而不用改变协议，但这些段不能假定接收者能识别。不可识别头段应被接收者忽略，而让代理转发。 连接RTSP请求可以几种不同方式传送： ·持久传输连接，用于多个请求/响应传输。 ·每个请求/响应传输一个连接。 ·无连接模式。 传输连接类型由RTSP URL来定义。对“rtsp'方案，需要持续连接；而"rtspu"

32、;方案，调用RTSP请求发送，而不用建立连接。 不像HTTP，RTSP允许媒体服务器给媒体用户发送请求。然而，这仅在持久连接时才支持，否则媒体服务器没有可靠途径到达用户，这也是请求通过防火墙从媒体服务器传到用户的惟一途径。 流水线操作支持持久连接或无连接的客户端可能给其请求排队。服务器必须以收到请求的同样顺序发出响应。如果请求不是发送给多播组，接收者就确认请求，如没有确认信息，发送者可在超过一个来回时间（RTT）后重发同一信息。 在TCP中RTT估计的初始值为500ms。应用缓存最后所测量的RTT，作为将来连接的初始值。如使用一个可靠传输协议传输RTSP，请求不允许重发，RTSP应用反过来依赖

33、低层传输提供可靠性。如两个低层可靠传输（如TCP和RTSP）应用重发请求，有可能每个包损失导致两次重传。由于传输栈在第一次尝试到达接收者前不会发送应用层重传，接收者也不能充分利用应用层重传。如包损失由阻塞引起，不同层的重发将使阻塞进一步恶化。时标头用来避免重发模糊性问题，避免对圆锥算法的依赖。每个请求在CSeq头中携带一个系列号，每发送一个不同请求，它就加一。如由于没有确认而重发请求，请求必须携带初始系列号。 实现RTSP的系统必须支持通过TCP传输RTSP，并支持UDP。对UDP和TCP，RTSP服务器的缺省端口都是554。许多目的一致的RTSP包被打包成单个低层PDU或TCP流。RTSP数

34、据可与RTP和RTCP包交叉。不像HTTP，RTSP信息必须包含一个内容长度头，无论信息何时包含负载。否则，RTSP包以空行结束，后跟最后一个信息头。 扩展RTSP由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同请求集。RTSP可以如下三种方式扩展： (1) 以新参数扩展。如用户需要拒绝通知，而方法扩展不支持，相应标记就加入要求的段中。 (2) 加入新方法。如信息接收者不理解请求，返回501错误代码，发送者不应再次尝试这种方法。用户可使用OPTIONS方法查询服务器支持的方法。服务器使用公共响应头列出支持的方法。 (3) 定义新版本协议，允许改变所有部分（协议版本号位置除外）。

35、操作模式每个演示和媒体流可用RTSP URL识别。演示组成的整个演示与媒体属性由演示描述文件定义。使用HTTP或其他途径用户可获得这个文件，它没有必要保存在媒体服务器上。为了说明这个问题，假设演示描述了多个演示，其中每个演示维持了一个公共时间轴。为简化说明，且不失一般性，假定演示描述的确包含这样一个演示。演示可包含多个媒体流。除媒体参数外，网络目标地址和端口也需要决定。 下面区分几种操作模式。 (1）单播：用户选择的端口号将媒体发送到RTSP请求源。 (2）服务器选择地址多播：媒体服务器选择多播地址和端口，这是现场直播或准点播常用的方式。 (3）用户选择地址多播：如服务器加入正在进行的多播会议

36、，多播地址、端口和密钥由会议描述给出。 RTSP状态RTSP控制通过单独协议发送的流，与控制通道无关。例如，RTSP控制可通过TCP连接，而数据流通过UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在连接生命期，单个媒体流可通过不同TCP连接顺序发出请求来控制。所以，服务器需要维持能联系流与RTSP请求的连接状态。RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的作用： (1) SETUP：让服务器给流分配资源，启动RTSP连接。 (2) PLAY与RECORD：启动SETUP分配流的数据传输。 (3) PAUSE：临时停止流，而不释放服务器资源。

37、(4) TEARDOWN：释放流的资源，RTSP连接停止。 标识状态的RTSP方法使用连接头段识别RTSP连接，为响应SETUP请求，服务器连接产生连接标识。 与其他协议的关系实时流协议在语法和操作上与HTTP/1.1类似，因此HTTP的扩展机制大都可加入RTSP。然而，在很多重要方面RTSP仍不同于HTTP： RTSP引入了大量新方法并具有一个不同的协议标识符； 在大多数情况下，RTSP服务器需要保持缺省状态，与HTTP的无状态相对； RTSP中客户端和服务器都可以发出请求； 在多数情况下，数据由不同的协议传输； RTSP使用ISO 10646（UTF-8）而并非ISO 8859-1，与当前

38、的国际标准HTML相一致； URI请求总是包含绝对URI。为了与过去的错误相互兼容，HTTP/1.1只在请求过程中传送绝对路径并将主机名置于另外的头字段。 RTSP在功能上与HTTP有重叠，与HTTP相互作用体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。例如，演示描述可通过HTTP和RTSP检索，这降低了浏览器的往返传递，也允许独立RTSP服务器与用户不全依靠HTTP。 但是，RTSP与HTTP的本质差别在于数据发送以不同协议进行。HTTP是不对称协议，用户发出请求，服务器作出响应。RTSP中，媒体用户和服务器都可发出请

39、求，且其请求都是无状态的；在请求确认后很长时间内，仍可设置参数，控制媒体流。重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近时，在缓存、代理和授权上采用HTTP功能是有价值的。 当大多数实时媒体使用RTP作为传输协议时，RTSP没有绑定到RTP。RTSP假设存在演示描述格式可表示包含几个媒体流的演示的静态与临时属性。 微软与RTSP简述RTSP并非只是微软在用！这是一个公开的规范，在这个规范上开发了很多的流服务器。甚至Linux服务提供者和苹果的程序员也使用rtsp协议以及Real Networks流媒体。似乎整个世界的网络流传输都用这个协议。然而，微软并不只在rtsp上有所作

40、为。 微软和RTSP 在写这个文档的时候，微软正处于从首选MMS协议转换到首选采用RTSP协议的过程中。这个说明在Media Player 9.0版本和流媒体服务器2003版本之后，我们会看到微软将rtsp协议作为流媒体传输的主要协议。 随着时间慢慢的流逝，我们会发现mms协议正逐步走出人们的视野。It is only assumed that this is so MS can say they are being open with their protocols (rtsp is an open standard) while at the same time disregarding

41、the need to publicise their own MMS protocol once its gone from media player. 然而，mms还没有真的死亡，至少在接下来的几年中我们依然可以看到它在流媒体传输中的身影。 是否微软的RTSP协议和标准的开放式RTSP不同？ 是的。跟在RFC2326（1998年四月）中定义的原始RTSP协议相比，微软的rtsp协议有一些轻微的改动。我们网站上有本文档（还有后续版本）和一个简单的研究，它们可以帮助你了解这些信息。 区别微软的rtsp规范与标准rtsp协议相比最主要的改动是发送包payloads到客户端的方式，另外还有一些请求

42、命令有一些改动。传输单个媒体包的机制并没有文档（就我目前所知），这可能是微软要保留的信息。就像MMS和HTTP 1.0流协议使用一个媒体数据包头一样，RTSP也有。但是微软的数据包头格式没有在任何的rtsp文档中注明。在企图连接微软的rtsp服务器时，这是主要的问题。 微软RTSP协议的命令采用的语法和标准rtsp协议的命令语法一样，只有一些小的修改和添加，可以通过阅读网上的一些文档，就可以知道怎么去组成这些命令。微软rtsp命令部分已经有文档了。3、 技术综述报告 随着Internet的迅猛发展，流媒体技术已经广泛应用于新闻发布、广播电视、教育、金融、视频会议、安防等领域，对人们的工作及生活

43、方式产生深远的影响。本文通过对现有的流媒体技术的原理、系统构成、传输协议等的总结分析，系统的介绍了流媒体的基本概念及特点，研究了流媒体的关键技术，并从用户的角度对流媒体的应用前景做了展望。 关键词：流媒体；传输协议；系统结构 流媒体（Streaming Media）是指采用流式传输的方式在Internet播放的多媒体格式。在流媒体出现之前，人们在互联网上获取音视频信息的唯一方式就是将音视频文件下载到本地计算机进行观看。而流媒体技术把连续的影像和声音信息以数据流的方式实时发布，即边下边播的方式，使得用户无需等待下载或只需少量时间缓冲即可观看，大大提高了音视频信息的可观赏性，节约用户时间及系统资源

44、。自从1995年progressive Network公司（即RealNetwork公司）发布第一个流产品以来，流媒体得到巨大的发展，已经成为目前互联网上呈现音、视频信息的主要方式。1. 流媒体传输的方法流媒体传输技术分为两类：:顺序流传输(Progressive streaming )和实时流传输(Realtime streaming)。顺序流方式又叫渐进式下载，其传输方式是顺序下载，在下载文件的同时用户可观看在线内容，用户只能观看已下载的部分，而不能跳到还未下载的部分。由于标准的HTTP服务器可发送顺序流式传输的文件，也不需要其他特殊协议，所以顺序流式传输经常被称作HTTP流式传输。实时流

45、方式：实时流式传输使媒体可被实时观看到，特别适合现场广播并提供VCR 功能，具备交互性，可以在播放的过程中响应用户的快进或后退等操作。实时流式传输必须匹配网络带宽，其出错的部分一般被忽略，传输质量特别时低带宽时的质量要比顺序传输的差。实时流传输需要专门的流媒体服务器和流传输协议。2. 流媒体技术原理流式传输方式是指通过特定算法将音频和视频等多媒体文件分解成多个小的数据包，由服务器向客户端连续传送，用户可播放已经接收到的数据包，而不需要将整个文件下载到客户端。由于TCP协议不太适合传输多媒体数据，故在实时流媒体方案中，一般采用HTTP/TCP来传输控制信息，而用RTP/UDP来传输实时数据。3.

46、 流媒体技术的系统结构目前不同公司的流媒体解决方案各不相同。但就其本质来说，一个完整的流媒体系统至少包括三个组件:编码工具、服务器及播放器。这三个组件间通过特定的通信协议相互联系，按特定的格式相互交换数据。4. 传输协议流媒体系统各组件通过传输协议相互通信。对于顺序流传输，可采用HTTP协议进行传输。但HTTP协议并不适合传输实时流数据。在流式传输的实现方案中，一般采用HTTP/TCP来传输控制信息，而用RTP/UDP来传输实时多媒体数据。传输协议是流媒体技术的一个重要组成部分，也是基础组成部分。它包括"RSVP(资源预留协议)"、"RTP(实时传输协议)&quo

47、t;、"R T C P (实时传输控制协议)" 和"RTSP(实时流协议)"，这四种协议构成了"rea1-time"服务的基础。4.1 资源预留协议RSVP (Resource Reserve Protocol)RSVP是Internet上的资源预订协议，使用RSVP可以让流数据的接收者主动请求流数据上的路由器，为该数据流预留一分网络资源（即带宽），在一定程度上为流媒体的传输提供服务质量。4.2 实时传输协议RTP与RTCPRTP是用于Internet/Intranet针对多媒体数据流的一种传输协议。RTP被定义为在一对一或一对多传输

48、的情况下工作，其目的是提供时间信息和实现流同步。RTP通常使用UDP来传送数据，但它本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。RTCP和RTP一起提供流量控制和拥塞控制服务。RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，特别适合传送网上的实时数据。4.3 实时流协议RTSP RTSP是由Real Networks和Netscape共同提出的，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。RTSP 是应用级协议，它以底层的RTP和RSVP为依托，控制实时数据的发送，它提供了可扩展框架，使实时数据的受控、点播成为可能。在客户端应用程序中对流式多媒体内容的播放、暂停等操作都是通过RTSP协议实现的。4.4 MMS协议（Microsoft Media Serve