嗅探器的设计与实现.docx
《嗅探器的设计与实现.docx》由会员分享，可在线阅读，更多相关《嗅探器的设计与实现.docx（18页珍藏版）》请在冰豆网上搜索。
嗅探器的设计与实现
目录
1、问题背景概述
二、协议分析说明分析
2.1RTSP总结
2.2MMS总结
2.3RTSP总结
三、技术综述报告
四、前景展望
1、问题背景概述
流媒体指在Internet/Intranet中使用流式传输技术的连续时基媒体，如：
音频、视频或多媒体文件。
流式媒体在播放前并不下载整个文件，只将开始部分内容存入内存，流式媒体的数据流随时传送随时播放，只是在开始时有一些延迟。
流媒体实现的关键技术就是流式传输。
常见的流媒体协议有以下几种：
1、RTMP（RealTimeMessagingProtocol），这是Adobe公司开发的流媒体传输协议，使用FlashMediaServer来搭建。
2、MMS（MediaServerProtocol,MMS），这是微软定义的一种流媒体传输协议，可使用WIndowsMediaServer搭建。
3、即时串流通讯协议（RealTimeStreamingProtocol，RTSP），它是RealNetworks公司协助建立的一个用来传送串流媒体的开放网页标准，使用RealServer服务器搭建环境。
二、协议分析说明分析
2.1RTSP总结
RealTime.1RMessagingProtocol（实时消息传送协议协议）概述
实时消息传送协议是AdobeSystems公司为Flash播放器和服务器之间音频、视频和数据传输开发的私有协议。
它有三种变种：
1）工作在TCP之上的明文协议，使用端口1935；
2）RTMPT封装在HTTP请求之中，可穿越防火墙；
3）RTMPS类似RTMPT，但使用的是HTTPS连接；
介绍:
RTMP协议是被Flash用于对象,视频,音频的传输.该协议建立在TCP协议或者轮询HTTP协议之上.
RTMP协议就像一个用来装数据包的容器,这些数据可以是AMF格式的数据,也可以是FLV中的视/音频数据.
一个单一的连接可以通过不同的通道传输多路网络流.这些通道中的包都是按照固定大小的包传输的.
下面的文档详细说明了RTMP消息块流。
它位高层多媒体流协议提供多路技术和包服务
RTMP消息块流是为RTMP协议设计的。
他可以处理任何传送消息流的协议。
每一个消息包含时间戳合有效负载类型标示。
RTMP消息块流和RTMP一起适用于多样性音视频应用程序，从一对一和一对多向视频点播服务器直接广播到交互式会议应用程序。
当用到实时传输协议就像TCP，RTMP消息块流提供可靠地规则时间戳的端到端全信息传送。
穿过多层流，RTMP消息块流不提供任何控制的优先级别和相似形式，但是可以用于高层协议提供这样的优先级。
例如，一段实时视频服务会选择丢弃给于缓慢的客户的视频信息确保音频信息可以及时被接收。
RTMP消息块流包含它自己的入队协议控制消息，也提供一个高层协议机制用于嵌入用户的控制消息。
2.定义
有效负载?
包含在包中的数据，就像音频样本或者压缩的视频数据。
包：
一个数据包由固定的包头和有效负载数据组成，一些底层协议或许需要包的封装来被定义
端口：
在TCP/P协议中定义的用正整数表示的端口号用于在传输中提取以区分目标主机的不同应用于OSI传输层的传输选择。
TSEL就是端口。
传输地址：
网络地址和端口的组合识别一个传输层终端端口。
例如一个IP地址和TCP端口。
数据包从一个源传：
输层地址传送到目标段的传输层地址。
消息流：
一个通信的逻辑通道，允许消息流通。
消息流ID：
?
?
每一个消息拥有一个分配的ID识别跟随的消息流。
消息快：
消息的片段，消息被分成小的部分。
在他们在网络中发送之前交叉存储。
消息块确保定制时间戳的端到端全消息传送穿过多层流。
消息块流：
一个通信的逻辑通道允许消息块在一个特定的方向上流通，消息块流可以从客户端传送到服务器也可以相反。
消息块流ID:
每一个消息块有一个分配的ID用于识别更随的消息块流。
复合技术:
把分开的音视频数据组合成一条音视频流的过程，使同时传送许多音视频数据成为可能。
逆复合技术:
复合的反向过程?
交叉存取组装的音频视频数据，使他们成为最初的音视频数据
3?
?
字节顺序，列队和时间格式
所有的整数字段有被网络字节负载着，字节0是第一个显示出来的?
.也是一段文字和字段中最重要的。
这种字节顺序一般被认为“大字节”.数字常量在这种文档里是用十进制表示。
所有RTMP消息块流是以用字节列队，例如，一个16字节的字段也许会在字数字节的偏移段。
那里要填充被标示?
.填充字节应该有0值。
在RTMP消息块流中的时间戳用整数表示，单位为毫秒。
每一个消息块流以时间戳0开始但是这不是必须的，只要两个终端在时间点上达成一致，注意那就意味着任何穿过多消息块流异步传输（特别是分散的主机）.在RTMP消息块流之外需要一些而外的机制。
时间戳必须始终在线性的增加，允许应用程序处理异步传输，带宽度量，检测和流控制。
因为时间戳一般是只有32字节的长度，他们周期小于50天，因为六流是允许不停地流动的，最终可以运行几年。
一个RTMP消息块流应用必须用到模运算用于相减和比较，任何合理的方式都可以被接受，只要两端都达成一致。
一个应用可以假设，例如，所有相近的时间戳在2的31次方以内。
所以10000在4000000000后面?
.3000000000在4000000000前面。
时间戳delta作为一个表示毫秒的无符号整数也会被详细介绍，和先前的时间戳相比，时间戳delta可以是24字节或者是32字节的长度4。
?
?
消息格式：
一个消息的格式可以分裂成消息块以支持复用，依靠高层协议，消息格式应该包含创造消息块的必须字段。
时间戳：
消息的时间戳，这个字段可以传输4个字节。
长度：
消息的有效负载的长度，如果消息头不能被省略，他应该包含在长度中，这个字段在消息块包头中占有3个字节。
类型ID：
?
?
协议控制消息的类型字段的范围是被保留的，这些传播信息的消息被RTMP消息块和高层协议处理。
所有其他的类型ID可被高层协议使用，被RTMP消息块当做不透明的值事实上在RTMP消息块中需要这些值当做类型的是没有的，所有的消息可以成为通一种类型。
或者应用程序用这个字段区分同步迹象而不是类型，这个字段占用1个字节。
消息流ID:
消息流ID可以是任意值，不同的消息复合依靠的同样的消息块流是基于他们的消息流ID被逆复合而成的，在此之上，直到RTMP消息块被关注，这是一个不透明的值，这个字段在包头中占用4个字节。
5?
?
握手
一个RTMP通信以握手开始，握手不像其他的协议，他包含三个固定长度的消息块。
客户（初始化通信的终端）和服务器每放发送同样的三个消息块，说明一下，被客户段发送的消息块被指定为C0，C1，C2，被服务器端发送的消息被指定为S0，S1，S2。
2.2MMS总结
MMS（MicrosoftMediaServerProtocol），中文“微软媒体服务器协议”，用来访问并流式接收WindowsMedia服务器中.asf文件的一种协议。
MMS协议用于访问WindowsMedia发布点上的单播内容。
MMS是连接WindowsMedia单播服务的默认方法。
若观众在WindowsMediaPlayer中键入一个URL以连接内容，而不是通过超级链接访问内容，则他们必须使用MMS协议引用该流。
MMS的预设埠（端口）是1755。
当使用MMS协议连接到发布点时，使用协议翻转以获得最佳连接。
“协议翻转”始于试图通过MMSU连接客户端。
MMSU是MMS协议结合UDP数据传送。
如果MMSU连接不成功，则服务器试图使用MMST。
MMST是MMS协议结合TCP数据传送。
如果连接到编入索引的.asf文件，想要快进、后退、暂停、开始和停止流，则必须使用MMS。
不能用UNC路径快进或后退。
若您从独立的WindowsMediaPlayer连接到发布点，则必须指定单播内容的URL。
若内容在主发布点点播发布，则URL由服务器名和.asf文件名组成。
例如：
mms:
//windows_media_server/sample.asf。
其中windows_media_server是WindowsMedia服务器名，sample.asf是您想要使之转化为流的.asf文件名。
若您有实时内容要通过广播单播发布，则该URL由服务器名和发布点别名组成。
例如：
mms:
//windows_media_server/LiveEvents。
这里windows_media_server是WindowsMedia服务器名，而LiveEvents是发布点名。
MMS是MultimediaMessagingService的缩写，中文译为多媒体信息服务，也称“彩信”，是按照3GPP的标准也是WAP论坛的标准有关多媒体信息的标准开发的最新业务，它最大的特色就是支持多媒体功能，可以在GPRS、CDMA1X、3G、EDGE的支持下，以WAP无线应用协议为载体传送视频短片、图片、声音和文字，传送方式除了在手机间传送外，还可以是手机与电脑之间的传送。
具有MMS功能的移动电话的独特之处在于其内置的媒体编辑器，使用户可以很方便地编写多媒体信息。
如果手机具有一个内置或外置的照相机，用户便可以制作出PowerPoint格式的信息或电子明信片，并把他们传送给朋友或同事。
目前，这一应用服务已逐渐走向成熟，成为主流的短信格式。
2.3RTSP总结
RTSP（RealTimeStreamingProtocol），实时流传输协议，是TCP/IP协议体系中的一个应用层协议，由哥伦比亚大学、网景和RealNetworks公司提交的IETFRFC标准。
该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。
RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。
HTTP与RTSP相比，HTTP传送HTML，而RTSP传送的是多媒体数据。
HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。
概念
RTSP是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP1.1类似，但并不特别强调时间同步，所以比较能容忍网
RTSP
络延迟。
而前面提到的允许同时多个串流需求控制（Multicast），除了可以降低服务器端的网络用量，更进而支持多方视讯会议（VideoConference）。
因为与HTTP1.1的运作方式相似，所以代理服务器〈Proxy〉的快取功能〈Cache〉也同样适用于RTSP，并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。
简介
该协议用于C/S模型，是一个基于文本的协议，用于在客户端和服务器端建立和协商实时流会话。
实时流协议（RTSP）是应用级协议，控制实时数据的发送。
RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控点播成为可能。
数据源包括现场数据与存储在剪辑中数据。
该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。
实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。
尽管连续媒体流与控制流交换是可能的，通常它本身并不发送连续流。
换言之，RTSP充当多媒体服务器的网络远程控制。
RTSP连接没有绑定到传输层连接，如TCP。
在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可传输连接以发出RTSP请求。
此外，可使用无连接传输协议，如UDP。
RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。
协议支持的操作如下：
（1）从媒体服务器上检索媒体：
用户可通过HTTP或其它方法提交一个演示描述。
如演示是组播，演示式就包含用于连续媒体的的组播地址和端口。
如演示仅通过单播发送给用户，用户为了安全应提供目的地址。
（2）媒体服务器邀请进入会议：
媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。
这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。
（3）将媒体加到现成讲座中：
如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。
如HTTP/1.1中类似，RTSP请求可由代理、通道与缓存处理。
协议特点
（1）可扩展性：
新方法和参数很容易加入RTSP。
（2）易解析：
RTSP可由标准HTTP或MIME解析器解析。
（3）安全：
RTSP使用网页安全机制。
（4）独立于传输：
RTSP可使用不可靠数据报协议（EDP）、可靠数据报协议（RDP）；如要实现应用级可靠，可使用可靠流协议。
（5）多服务器支持：
每个流可放在不同服务器上，用户端自动与不同服务器建立几个并发控制连接，媒体同步在传输层执行。
（6）记录设备控制：
协议可控制记录和回放设备。
（7）流控与会议开始分离：
仅要求会议初始化协议提供，或可用来创建惟一会议标识号。
特殊情况下，可用SIP或H.323来邀请服务器入会。
（8）适合专业应用：
通过SMPTE时标，RTSP支持帧级精度，允许远程数字编辑。
（9）演示描述中立：
协议没强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少必须包括一个RTSPURL。
（10）代理与防火墙友好：
协议可由应用和传输层防火墙处理。
防火墙需要理解SETUP方法，为UDP媒体流打开一个“缺口”。
（11）HTTP友好：
此处，RTSP明智地采用HTTP观念，使现在结构都可重用。
结构包括Internet内容选择平台（PICS）。
由于在大多数情况下控制连续媒体需要服务器状态，RTSP不仅仅向HTFP添加方法。
（12）适当的服务器控制：
如用户启动一个流，必须也可以停止一个流。
（13）传输协调：
实际处理连续媒体流前，用户可协调传输方法。
（14）性能协调：
如基本特征无效，必须有一些清理机制让用户决定哪种方法没生效。
这允许用户提出适合的用户界面。
协议结构
RTSP是一种文本协议，采用UTF-8编码中的ISO10646字符集。
一行可通过CRLF终止，但接收端需要做好解释CR和LF作为一行终止符的准备。
关于头字段概述如下：
HeaderTypeSupportMethods AcceptRopt.entity Accept-Encoding Ropt.entity Accept-LanguageRopt.all Allow Ropt.all AuthorizationRopt.all BandwidthRopt.all BlocksizeRopt.AllbutOPTIONS,TEARDOWN Cache-ControlGopt.SETUP ConferenceRopt.SETUP ConnectionGreq.all Content-BaseEopt.entity Content-EncodingEreq.SET_PARAMETER Content-EncodingE req.DESCRIBE,ANNOUNCE Content-LanguageEreq.DESCRIBE,ANNOUNCE Content-LengthE req.SET_PARAMETER,ANNOUNCE Content-LengthEreq.entity Content-LocationEopt.entity Content-TypeEreq.SET_PARAMETER,ANNOUNCE Content-TypeRreq.entity CSeqGreq.all DateGopt.all ExpiresEopt.DESCRIBE,ANNOUNCE FromRopt.all If-Modified-SinceRopt.DESCRIBE,SETUP Last-ModifiedEopt.entity Proxy-Authenticate Proxy-RequireRreq.all PublicRopt.all RangeRopt.PLAY,PAUSE,RECORD RangeRopt.PLAY,PAUSE,RECORD RefererRopt.all RequireRreq.all Retry-AfterRopt.all RTP-InfoRreq.PLAY ScaleRropt.PLAY,RECORD Session Rrreq.AllbutSETUP,OPTIONS ServerRopt.all SpeedRropt.PLAY TransportRrreq.SETUP Unsupported Rreq.all User-Agent Ropt.all Via Gopt.all WWW-Authenticate Ropt.all 类型"g"表示请求和响应中的通用请求头；类型“R”表示请求头；类型“r”表示响应头；类型"e"表示实体头字段。
在“support”一栏中标有“req.”的字段必须由接收者以特殊的方法实现；而“opt.”的字段是可选的。
注意，不是所有“req.”字段在该类型的每个请求中都会被发送。
“req.”只表示客户机（支持响应头）和服务器（支持请求头）必须执行该字段。
最后一栏列出了关于头字段产生作用的方法；其中“entity”针对于返回一个信息主体的所有方法。
协议参数
1．RTSP版本 H.321采用，用RTSP代替HTTP。
2．RTSPURL “rksp"和“rtspu"方案用于指RTSP协议使用的网络资源，为RTSPURL定义方案特定的语法和语义。
3．会议标识 会议标识对RTSP来说是模糊的，采用标准URI编码方法编码，可包含任何八位组数值。
会议标识必须全局惟一。
4．连接标识 连接标识是长度不确定的字符串，必须随机选择，至少要8个八位组长，使其很难被猜出。
5．SMPTE相关时标 SMPTE相关时标表示相对剪辑开始的时间，相关时标表示成SMPTE时间代码，精确到帧级。
时间代码格式为小时：
分钟：
秒：
帧。
缺省smpte格式是"SMPTE30"，帧速率为每秒29.97帧。
其他SMPTE代码可选择使用smpte时间获得支持（如"SMPIE25"）。
时间数值中帧段值可从0到29。
每秒30与29.97帧的差别可将每分钟的头两帧丢掉来实现。
如帧值为零，就可删除。
6．正常播放时间 正常播放时间（NPT）表示相对演示开始的流绝对位置。
时标由十进制分数组成。
左边部分用秒或小时、分钟、秒表示；小数点右边部分表示秒的部分。
演示的开始对应0.0秒，负数没有定义。
特殊常数定义成现场事件的当前时刻，这也许只用于现场事件。
直观上，NPT是联系观看者与程序的时钟，通常以数字式显示在VCR上。
7．绝对时间 绝对时间表示成ISO8601时标，采用UTC（GMT）。
8．可选标签 可选标签是用于指定RTSP新可选项的惟一标记。
这些标记用在请求和代理-请求头段。
当登记新RTSP选项时，需提供下列信息：
（1）名称和描述选项。
名称长度不限，但不应该多于20个字符。
名称不能包括空格、控制字符。
（2）表明谁改变选项的控制。
如IETF，ISO，ITU-T，或其他国际标准团体、联盟或公司。
（3）深入描述的参考，如RFC、论文、专利、技术报告、文档源码和计算机手册。
（4）对专用选项，附上联系方式。
RTSP信息
RTSP是基于文本的协议，采用ISO10646字符集，使用UTF-8编码方案。
行以CRLF中断，但接收者本身可将CR和LF解释成行终止符。
基于文本的协议使以自描述方式增加可选参数更容易。
由于参数的数量和命令的频率出现较低，处理效率没引起注意。
文本协议很容易以脚本语言（如：
Tcl，VisualBasic与Perl）实现研究原型。
ISO10646字符集避免敏感字符集切换，但对应用来说不可见。
RTCP也采用这种编码方案。
带有重要意义位的ISO8859-1字符表示如100001x10xxxxxx。
RTSP信息可通过任何低层传输协议携带。
请求包括方法、方法作用于其上的对象以及进一步描述方法的参数。
方法也可设计为在服务器端只需要少量或不需要状态维护。
当信息体包含在信息中，信息体长度由如下因素决定：
（1）不管实体头段是否出现在信息中，不包括信息体的响应，信息总以头段后第一个空行结束。
（2）如出现内容长度头段，其值以字节计，表示信息体长度。
如未出现头段，其值为零。
（3）服务器关闭连接。
注意，RTSP目前并不支持HTTP1.1“块”传输编码，需要有内容长度头。
假如返回适度演示描述长度，即使动态产生，使块传输编码没有必要，服务器也应该能决定其长度。
如有实体，即使必须有内容长度，且长度没显式给出，规则可确保行为合理。
从用户到服务器端的请求信息在第一行内包括源采用的方法、源标识和所用协议版本。
RTSP定义了附加状态代码，但没有定义任何HTTP代码。
RTSP实体
如不受请求方法或响应状态编码限制，请求和响应信息可传输实体，实体则由实体头文件和实体体组成，有些响应仅包括实体头。
在此，根据谁发送实体、谁接收实体，发送者和接收者可分别指用户和服务器。
实体头定义实体体可选元信息，如没有实体体，指请求标识的资源。
扩展头机制允许定义附加实体头段，而不用改变协议，但这些段不能假定接收者能识别。
不可识别头段应被接收者忽略，而让代理转发。
连接
RTSP请求可以几种不同方式传送：
· 持久传输连接，用于多个请求/响应传输。
· 每个请求/响应传输一个连接。
· 无连接模式。
传输连接类型由RTSPURL来定义。
对“rtsp'’方案，需要持续连接；而"rtspu"方案，调用RTSP请求发送，而不用建立连接。
不像HTTP，RTSP允许媒体服务器给媒体用户发送请求。
然而，这仅在持久连接时才支持，否则媒体服务器没有可靠途径到达用户，这也是请求通过防火墙从媒体服务器传到用户的惟一途径。
流水线操作
支持持久连接或无连接的客户端可能给其请求排队。
服务器必须以收到请求的同样顺序发出响应。
如果请求不是发送给多播组，接收者就确认请求，如没有确认信息，发送者可在超过一个来回时间（RTT）后重发同一信息。
在TCP中RTT估计的初始值为500ms。
应用缓存最后所测量的RTT，作为将来连接的初始值。
如使用一个可靠传输协议传输RTSP，请求不允许重发，RTSP应用反过来依赖低层传输提供可靠性。
如两个低层可靠传输（如
升级会员 