UDP、TCP、RTP协议总结

('UDP、TCP、RTP三种协议的总结一、RTP协议分析1、RTP概述1.1.RTP是什么RTP全名是Real-timeTransportProtocol〔实时传输协议〕。它是IETF提出的一个标准，对应的RFC文档为RFC3550〔RFC1889为其过期版本〕。RFC3550不仅定义了RTP，而且定义了配套的相关协议RTCP〔Real-timeTransportControlProtocol，即实时传输把握协议〕。RTP用来为IP网上的语音、图像、等多种需要实时传输的多媒体数据供给端到端的实时传输效劳。RTP为Internet上端到端的实时传输供给时间信息和流同步，但并不保证效劳质量，效劳质量由RTCP来供给。1.2.RTP的应用环境RTP用于在单播或多播网络中传送实时数据。它们典型的应用场合有如下几个。（1）简洁的多播音频会议。语音通信通过一个多播地址和一对端口来实现。一个用于音频数据〔RTP〕，另一个用于把握包〔RTCP〕。（2）音频和视频会议。假设在一次会议中同时使用了音频和视频会议，这两种媒体将分别在不同的RTP会话中传送，每一个会话使用不同的传输地址〔IP地址＋端口〕。假设一个用户同时使用了两个会话，则每个会话对应的RTCP包都使用标准化名字CNAME〔CanonicalName〕。与会者可以依据RTCP包中的CNAME来猎取相关联的音频和视频，然后依据RTCP包中的计时信息(Networktimeprotocol)来实现音频和视频的同步。（3）翻译器和混合器。翻译器和混合器都是RTP级的中继系统。翻译器用在通过IP多播不能直接到达的用户区，例如发送者和接收者之间存在防火墙。当与会者能接收的音频编码格式不一样，比方有一个与会者通过一条低速链路接入到高速会议，这时就要使用混合器。在进入音频数据格式需要变化的网络前，混合器将来自一个源或多个源的音频包进展重构，并把重构后的多个音频合并，承受另一种音频编码进展编码后，再转发这个的RTP包。从一个混合器出来的全部数据包要用混合器作为它们的同步源〔SSRC，见RTP的封装〕来识别，可以通过奉献源列表〔CSRC表，见RTP的封装〕可以确认谈话者。1.3.流媒体流媒体是指Internet上使用流式传输技术的连续时基媒体。当前在Internet上传输音频和视频等信息主要有两种方式：下载和流式传输两种方式。下载状况下，用户需要先下载整个媒体文件到本地，然后才能播放媒体文件。在视频直播等应用场合，由于生成整个媒体文件要等直播完毕，也就是用户至少要在直播完毕后才能看到直播节目，所以用下载方式不能实现直播。流式传输是实现流媒体的关键技术。使用流式传输可以边下载边观看流媒体节目。由于Internet是基于分组传输的，所以接收端收到的数据包往往有延迟和乱序〔流式传输构建在UDP上〕。要实现流式传输，就是要从降低延迟和恢复数据包时序入手。在发送端，为降低延迟，往往对传输数据进展预处理〔降低质量和高效压缩〕。在接收端为了恢复时序，承受了接收缓冲；而为了实现媒体的流畅播放，则承受了播放缓冲。使用接收缓冲，可以将接收到的数据包缓存起来，然后依据数据包的封装信息〔如包序号和时戳等〕，将乱序的包重排序，最终将重排序了的数据包放入播放缓冲播放。为什么需要播放缓冲呢？简洁想到，由于网络不行能很抱负，并且对数据包排序需要处理时耗，我们得到排序好的数据包的时间间隔是不等的。假设不用播放缓冲，那么播放节目会很卡，这叫时延抖动。相反，使用播放缓冲，在开头播放时，花费几十秒钟先将播放缓冲填满〔例如PPLIVE〕，可以有效地消退时延抖动，从而在不太损失实时性的前提下实现流媒体的顺畅播放。到目前为止,Internet上使用较多的流式视频格式主要有以下三种:RealNetworks公司的RealMedia,Apple公司的QuickTime以及Microsoft公司的AdvancedStreamingFormat(ASF)。上面在谈接收缓冲时，说到了流媒体数据包的封装信息〔包序号和时戳等〕，这在后面的RTP封装中会有表达。另外，RealMedia这些流式媒体格式只是编解码有不同，但对于RTP来说，它们都是待封装传输的流媒体数据而没有什么不同。2、RTP详解2.1.RTP的协议层次2.1.1.传输层的子层RTP〔实时传输协议〕，顾名思义它是用来供给实时传输的，因而可以看成是传输层的一个子层。图1给出了流媒体应用中的一个典型的协议体系构造。图2给出了RTP协议与其他协议之间的关系。图1流媒体体系构造图2RTP协议与其他协议的关系从图中可以看出，RTP被划分在传输层，它建立在UDP上。同UDP协议一样，为了实现其实时传输功能，RTP也有固式。RTP用来为端到端的实时传输供给时间信息和流同步，但并不保证效劳质量。效劳质量由RTCP来供给。2.1.2.应用层的一局部不少人也把RTP归为应用层的一局部，这是从应用开发者的角度来说的。操作系统中的TCP/IP等协议栈所供给的是我们最常用的效劳，而RTP的实现还是要靠开发者自己。因此从开发的角度来说，RTP的实现和应用层协议的实现没不同，所以可将RTP看成应用层协议。RTP实现者在发送RTP数据时，需先将数据封装成RTP包，而在接收到RTP数据包，需要将数据从RTP包中提取出来。2.2.RTP的封装一个协议的封装是为了满足协议的功能需求的。从前面提出的功能需求，可以推想出RTP封装中应当有同步源和时戳等字段，但更为完整的封装是什么样子呢？请看图3。图3RTP的头部格式版本号〔V〕：2比特，用来标志使用的RTP版本。填充位〔P〕：1比特，假设该位置位，则该RTP包的尾部就包含附加的填充字节。扩展位〔X〕：1比特，假设该位置位的话，RTP固定头部后面就跟有一个扩展头部。CSRC计数器〔CC〕：4比特，含有固定头部后面跟着的CSRC的数目。标记位〔M〕：1比特,该位的解释由配置文档〔Profile〕来担当.载荷类型〔PT〕：7比特，标识了RTP载荷的类型。序列号〔SN〕：16比特，发送方在每发送完一个RTP包后就将该域的值增加1，接收方可以由该域检测包的丧失及恢复包序列。序列号的初始值是随机的。时间戳：32比特，记录了该包中数据的第一个字节的采样时刻。在一次会话开头时，时间戳初始化成一个初始值。即使在没有信号发送时，时间戳的数值也要随时间而不断地增加〔时间在消逝嘛〕。时间戳是去除抖动和实现同步不行缺少的。同步源标识符(SSRC)：32比特，同步源就是指RTP包流的来源。在同一个RTP会话中不能有两个一样的SSRC值。该标识符是随机选取的RFC1889推举了MD5随机算法。奉献源列表〔CSRCList〕：0～15项，每项32比特，用来标志对一个RTP混合器产生的包有奉献的全部RTP包的源。由混合器将这些有奉献的SSRC标识符插入表中。SSRC标识符都被列出来，以便接收端能正确指出交谈双方的身份。2.3.RTCP的封装RTP需要RTCP为其效劳质量供给保证，因此下面介绍一下RTCP的相关学问。RTCP的主要功能是：效劳质量的监视与反响、媒体间的同步，以及多播组中成员的标识。在RTP会话期间，各参与者周期性地传送RTCP包。RTCP包中含有已发送的数据包的数量、丧失的数据包的数量等统计资料，因此，各参与者可以利用这些信息动态地转变传输速率，甚至转变有效载荷类型。RTP和RTCP协作使用，它们能以有效的反响和最小的开销使传输效率最正确化，因而特别适合传送网上的实时数据。从图1可以看到，RTCP也是用UDP来传送的，但RTCP封装的仅仅是一些把握信息，因而分组很短，所以可以将多个RTCP分组封装在一个UDP包中。RTCP有如下五种分组表1RTCP的5种分组类型上述五种分组的封装大同小异，下面只表达SR类型，而其它类型请参考RFC3550。发送端报告分组SR〔SenderReport〕用来使发送端以多播方式向全部接收端报揭露送状况。SR分组的主要内容有：相应的RTP流的SSRC，RTP流中最产生的RTP分组的时间戳和NTP，RTP流包含的分组数，RTP流包含的字节数。SR包的封装如图3所示。图3RTCP头部的格式版本〔V〕：同RTP包头域。填充〔P〕：同RTP包头域。接收报告计数器〔RC〕：5比特，该SR包中的接收报告块的数目，可以为零。包类型〔PT〕：8比特，SR包是200。长度域〔Length〕：16比特，其中存放的是该SR包以32比特为单位的总长度减一。同步源〔SSRC〕：SR包发送者的同步源标识符。与对应RTP包中的SSRC一样。NTPTimestamp〔Networktimeprotocol〕SR包发送时确实定时间值。NTP的作用是同步不同的RTP媒体流。RTPTimestamp：与NTP时间戳对应，与RTP数据包中的RTP时间戳具有一样的单位和随机初始值。Sender’spacketcount：从开头发送包到产生这个SR包这段时间里，发送者发送的RTP数据包的总数.SSRC转变时，这个域清零。Sender`soctetcount：从开头发送包到产生这个SR包这段时间里，发送者发送的净荷数据的总字节数〔不包括头部和填充〕。发送者转变其SSRC时，这个域要清零。同步源n的SSRC标识符：该报告块中包含的是从该源接收到的包的统计信息。丧失率〔FractionLost〕：说明从上一个SR或RR包发出以来从同步源n(SSRC_n)来的RTP数据包的丧失率。累计的包丧失数目：从开头接收到SSRC_n的包到发送SR,从SSRC_n传过来的RTP数据包的丧失总数。收到的扩展最大序列号：从SSRC_n收到的RTP数据包中最大的序列号，接收抖动〔Interarrivaljitter〕：RTP数据包承受时间的统计方差估量上次SR时间戳〔LastSR,LSR〕：取最近从SSRC_n收到的SR包中的NTP时间戳的中间32比特。假设目前还没收到SR包，则该域清零。上次SR以来的延时〔DelaysincelastSR,DLSR〕：上次从SSRC_n收到SR包到发送本报告的延时。2.4.RTP的会话过程当应用程序建立一个RTP会话时，应用程序将确定一对目的传输地址。目的传输地址由一个网络地址和一对端口组成，有两个端口：一个给RTP包，一个给RTCP包，使得RTP/RTCP数据能够正确发送。RTP数据发向偶数的UDP端口，而对应的把握信号RTCP数据发向相邻的奇数UDP端口〔偶数的UDP端口＋1〕，这样就构成一个UDP端口对。RTP的发送过程如下，接收过程则相反。1)RTP协议从上层接收流媒体信息码流〔如H.263〕，封装成RTP数据包；RTCP从上层接收把握信息，封装成RTCP把握包。2)RTP将RTP数据包发往UDP端口对中偶数端口；RTCP将RTCP把握包发往UDP端口对中的接收端口。二、TCP协议分析1、TCP协议简介TCP，全称TransferControlProtocol，中文名为传输把握协议，它工作在OSI的传输层，供给面对连接的牢靠传输效劳。TCP的工作主要是建立连接，然后从应用层程序中接收数据并进展传输。TCP承受虚电路连接方式进展工作，在发送数据前它需要在发送方和接收方建立一个连接，数据在发送出去后，发送方会等待接收方给出一个确认性的应答，否则发送方将认为此数据丧失，并重发送此数据。2、TCP报头TCP报头总长最小为20个字节，其报头构造如以以以以下图〔图1〕所示；比特0比特15比特16比特31TCP偏移量（4）源端口〔16〕保存〔6〕校验和〔16〕序列号〔32〕确认号〔32〕标志〔6〕选项〔0或32〕数据〔可变〕〔图1TCP报头构造〕目的端口〔16〕窗口〔16〕紧急〔16〕源端口：指定了发送端的端口目的端口：指定了承受端的端口号序号：指明白段在马上传输的段序列中的位置确认号：规定成功收到段的序列号，确认序号包含发送确认的一端所期望收到的下一个序号TCP偏移量：指定了段头的长度。段头的长度取决与段头选项字段中设置的选项保存：指定了一个保存字段，以备将来使用标志：SYN、ACK、PSH、RST、URG、FINSYN：表示同步ACK：表示确认PSH：表示尽快的将数据送往接收进程RST：表示复位连接URG：表示紧急指针FIN：表示发送方完成数据发送窗口：指定关于发送端能传输的下一段的大小的指令校验和：校验和包含TCP段头和数据局部，用来校验段头和数据局部的牢靠性紧急：指明段中包含紧急信息，只有当URG标志置1时紧急指针才有效选项：指定了公认的段大小，时间戳，选项字段的末端，以及指定了选项字段的边界选项3、TCP工作原理TCP连接建立：TCP的连接建立过程又称为TCP三次握手。首先发送方主机向接收方主机发起一个建立连接的同步〔SYN〕恳求；接收方主机在收到这个恳求后向送方主机回复一个同步/确认〔SYN/ACK〕应答；发送方主机收到此包后再向接收方主机发送一个确认〔ACK〕，此时TCP连接成功建立；TCP连接关闭：发送方主机和目的主机建立TCP连接并完成数据传输后，会发送一个将完毕标记置1的数据包，以关闭这个TCP连接，并同时释放该连接占用的缓冲区空间；TCP重置：TCP允许在传输的过程中突然中断连接，这称为TCP重置；TCP数据排序和确认：TCP是一种牢靠传输的协议，它在传输的过程中使用序列号和确认号来跟踪数据的接收状况；TCP重传：在TCP的传输过程中，假设在重传超时时间内没有收到接收方主机对某数据包确实认回复，发送方主机就认为此数据包丧失，并再次发送这个数据包给接收方，这称为TCP重传；TCP延迟确认：TCP并不总是在接收到数据后马上对其进展确认，它允许主机在接收数据的同时发送自己确实认信息给对方。TCP数据保护〔校验和〕：TCP是牢靠传输的协议，它供给校验和计算来实现数据在传输过程中的完整性。三、UDP协议分析1、UDP简介UDP协议是英文UserDatagramProtocol的缩写，即用户数据报协议，主要用来支持那些需要在计算机之间传输数据的网络应用。包括网络视频会议系统在内的众多的客户/效劳器模式的网络应用都需要使用UDP协议。UDP协议从问世至今已经被使用了很多年，虽然其最初的荣耀已经被一些类似协议所掩盖，但是即使是在今日，UDP照旧不失为一项格外有用和可行的网络传输层协议。与我们所熟知的TCP〔传输把握协议〕协议一样，UDP协议直接位于IP〔网际协议〕协议的顶层。依据OSI〔开放系统互连〕参考模型，UDP和TCP都属于传输层协议。UDP协议的主要作用是将网络数据流量压缩成数据报的形式。一个典型的数据报就是一个二进制数据的传输单位。每一个数据报的前8个字节用来包含报头信息，剩余字节则用来包含具体的传输数据。2、UDP协议构造UDP报头由4个域组成，其中每个域各占用2个字节，具体如下：源端口号、目标端口号、数据报长度和校验值。UDP协议使用端口号为不同的应用保存其各自的数据传输通道。UDP和TCP协议正是承受这一机制实现对同一时刻内多项应用同时发送和接收数据的支持。数据发送一方〔可以是客户端或效劳器端〕将UDP数据报通过源端口发送出去，而数据接收一方则通过目标端口接收数据。有的网络应用只能使用预先为其预留或注册的静态端口；而另外一些网络应用则可以使用未被注册的动态端口。由于UDP报头使用两个字节存放端口号，所以端口号的有效范围是从0到65535。一般来说，大于49151的端口号都代表动态端口。数据报的长度是指包括报头和数据局部在内的总的字节数。由于报头的长度是固定的，所以该域主要被用来计算可变长度的数据局部〔又称为数据负载〕。数据报的最大长度依据操作环境的不同而各异。从理论上说，包含报头在内的数据报的最大长度为65535字节。不过，一些实际应用往往会限制数据报的大小，有时会降低到8192字节。UDP协议使用报头中的校验值来保证数据的安全。校验值首先在数据发送方通过特别的算法计算得出，在传递到接收方之后，还需要再重计算。假设某个数据报在传输过程中被第三方篡改或者由于线路噪音等缘由受到损坏，发送和接收方的校验计算值将不会相符，由此UDP协议可以检测是否出错。这与TCP协议是不同的，后者要求必需具有校验值。四、三种协议比照RTP位于UDP之上，UDP虽然没有TCP那么牢靠，并且无法保证明时业务的效劳质量，需要RTCP实时监控数据传输和效劳质量，但是，由于UDP的传输时延低于TCP，能与视频和音频很好匹配。因此，在实际应用中，RTP/RTCP/UDP用于音频/视频媒体，而TCP用于数据和把握信令的传输。UDP和TCP协议的主要区分是两者在如何实现信息的牢靠传递方面不同。TCP协议中包含了特地的传递保证机制，当数据接收方收到发送方传来的信息时，会自动向发送方发出确认消息；发送方只有在接收到该确认消息之后才连续传送其它信息，否则将始终等待直到收到确认信息为止。连接是否确保是否支持组播支持不支持支持所以TCP必UDP多了建立连接的时间。相对UDP而言，TCP具有更高的安全性和牢靠性。TCP协议传输的大小不限制，一旦连接被建立，双方可以依据确定的格式传输大量的数据，而UDP是一个不行靠的协议，大小有限制，每次不能超过64K。相对于TCP协议，UDP协议的另外一个不同之处在于如何接收突法性的多个数据报。不同于TCP，UDP并不能确保数据的发送和接收挨次。三者的性能比照见表1。表1三种协议的性能比照协议名称简洁性建立时间牢靠性数据报发送和承受挨次实时性适用范围RTP/RTCP低少低否是实时音视TCP高多高是否频媒体传输数据和把握信令传输UDP低少低否否音视频媒体传输',)