rtp、udp、tcp协议介绍

客官°小女子只卖身不卖艺 2022-04-08 14:11 481阅读 0赞

**OSI七层模型**  
OSI 中的层            功能                                                        TCP/IP协议族   
应 用层                 文件传输，电子邮件，文件服务，虚拟终 端         TFTP，HTTP，SNMP，FTP，SMTP，DNS，Telnet   
表示层                 数据格式化，代码转换，数据加密                                    没有协议   
会话 层                 解除或建立与别的接点的联系                                          没有协议   
传输层                 提供端对端的接口                                                        TCP，UDP （RTP）  
网 络层                 为数据包选择路由                                                        IP，ICMP，RIP，OSPF，BGP，IGMP   
数据链路层           传输有地址的帧以及错误检测功能                            SLIP，CSLIP，PPP，ARP，RARP，MTU   
物 理层                 以二进制数据形式在物理媒体上传输数据                             ISO2110，IEEE802，IEEE802.2

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

**TCP/IP五层模型的协议**

应用层   
传输层：四层交换机、也有工作在四层的路由器

网络层：路由器、三层交换机

数据链路层：网桥（现已很少使用）、以太网交换机（二层交换机）、网卡（其实网卡是一半工作在物理层、一半工作在数据链路层）

物理层：中继器、集线器、还有我们通常说的双绞线也工作在物理层

**一、****RTP****协议分析**

**1****、  RTP****概述**

**1.1.  RTP****是什么**

RTP全名是Real-time Transport Protocol（实时传输协议）。它是IETF提出的一个标准，对应的RFC文档为RFC3550（RFC1889为其过期版本）。RFC3550不仅定义了RTP，而且定义了配套的相关协议RTCP（Real-time Transport Control Protocol，即实时传输控制协议）。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。RTP为Internet上端到端的实时传输提供时间信息和流同步，但并不保证服务质量，服务质量由RTCP来提供。

**1.2.  RTP****的应用环境**

RTP用于在单播或多播网络中传送实时数据。它们典型的应用场合有如下几个。

（1）简单的多播音频会议。语音通信通过一个多播地址和一对端口来实现。一个用于音频数据（RTP），另一个用于控制包（RTCP）。

（2）音频和视频会议。如果在一次会议中同时使用了音频和视频会议，这两种媒体将分别在不同的RTP会话中传送，每一个会话使用不同的传输地址（IP地址＋端口）。如果一个用户同时使用了两个会话，则每个会话对应的RTCP包都使用规范化名字CNAME（Canonical Name）。与会者可以根据RTCP包中的CNAME来获取相关联的音频和视频，然后根据RTCP包中的计时信息(Network time protocol)来实现音频和视频的同步。

（3）翻译器和混合器。翻译器和混合器都是RTP级的中继系统。翻译器用在通过IP多播不能直接到达的用户区，例如发送者和接收者之间存在防火墙。当与会者能接收的音频编码格式不一样，比如有一个与会者通过一条低速链路接入到高速会议，这时就要使用混合器。在进入音频数据格式需要变化的网络前，混合器将来自一个源或多个源的音频包进行重构，并把重构后的多个音频合并，采用另一种音频编码进行编码后，再转发这个新的RTP包。从一个混合器出来的所有数据包要用混合器作为它们的同步源（SSRC，见RTP的封装）来识别，可以通过贡献源列表（CSRC表，见RTP的封装）可以确认谈话者。

**1.3.  ****流媒体**

流媒体是指Internet上使用流式传输技术的连续时基媒体。当前在Internet上传输音频和视频等信息主要有两种方式：下载和流式传输两种方式。

下载情况下，用户需要先下载整个媒体文件到本地，然后才能播放媒体文件。在视频直播等应用场合，由于生成整个媒体文件要等直播结束，也就是用户至少要在直播结束后才能看到直播节目，所以用下载方式不能实现直播。

流式传输是实现流媒体的关键技术。使用流式传输可以边下载边观看流媒体节目。由于Internet是基于分组传输的，所以接收端收到的数据包往往有延迟和乱序（流式传输构建在UDP上）。要实现流式传输，就是要从降低延迟和恢复数据包时序入手。在发送端，为降低延迟，往往对传输数据进行预处理（降低质量和高效压缩）。在接收端为了恢复时序，采用了接收缓冲；而为了实现媒体的流畅播放，则采用了播放缓冲。

使用接收缓冲，可以将接收到的数据包缓存起来，然后根据数据包的封装信息（如包序号和时戳等），将乱序的包重新排序，最后将重新排序了的数据包放入播放缓冲播放。

为什么需要播放缓冲呢？容易想到，由于网络不可能很理想，并且对数据包排序需要处理时耗，我们得到排序好的数据包的时间间隔是不等的。如果不用播放缓冲，那么播放节目会很卡，这叫时延抖动。相反，使用播放缓冲，在开始播放时，花费几十秒钟先将播放缓冲填满（例如PPLIVE），可以有效地消除时延抖动，从而在不太损失实时性的前提下实现流媒体的顺畅播放。

到目前为止,Internet 上使用较多的流式视频格式主要有以下三种:RealNetworks 公司的RealMedia ,Apple 公司的QuickTime 以及Microsoft 公司的Advanced Streaming Format (ASF) 。

上面在谈接收缓冲时，说到了流媒体数据包的封装信息（包序号和时戳等），这在后面的RTP封装中会有体现。另外，RealMedia这些流式媒体格式只是编解码有不同，但对于RTP来说，它们都是待封装传输的流媒体数据而没有什么不同。

**2****、   RTP****详解**

**2.1.  RTP****的协议层次**

**2.1.1****.  ****传输层的子层**

RTP（实时传输协议），顾名思义它是用来提供实时传输的，因而可以看成是传输层的一个子层。图 1给出了流媒体应用中的一个典型的协议体系结构。图2给出了RTP协议与其他协议之间的关系。

![UDP、TCP、RTP三种协议的总结 - super-and-star - super-and-star的博客][UDP_TCP_RTP_ - super-and-star - super-and-star]

图1 流媒体体系结构

![UDP、TCP、RTP三种协议的总结 - super-and-star - super-and-star的博客][UDP_TCP_RTP_ - super-and-star - super-and-star 1]

图2 RTP协议与其他协议的关系

RTP、TCP、UDP都属于传输层协议; RTP也可以认为是介于应用层与传输层之间

从图中可以看出，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。

![UDP、TCP、RTP三种协议的总结 - super-and-star - super-and-star的博客][UDP_TCP_RTP_ - super-and-star - super-and-star 2]

图 3 RTP的头部格式

版本号（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随机算法。

贡献源列表（CSRC List）：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有如下五种分组

![UDP、TCP、RTP三种协议的总结 - super-and-star - super-and-star的博客][UDP_TCP_RTP_ - super-and-star - super-and-star 3]

表 1 RTCP的5种分组类型

上述五种分组的封装大同小异，下面只讲述SR类型，而其它类型请参考RFC3550。

发送端报告分组SR（Sender Report）用来使发送端以多播方式向所有接收端报告发送情况。SR分组的主要内容有：相应的RTP流的SSRC，RTP流中最新产生的RTP分组的时间戳和NTP，RTP流包含的分组数，RTP流包含的字节数。SR包的封装如图3所示。

![UDP、TCP、RTP三种协议的总结 - super-and-star - super-and-star的博客][UDP_TCP_RTP_ - super-and-star - super-and-star 4]

图 3 RTCP头部的格式

版本（V）：同RTP包头域。

填充（P）：同RTP包头域。

接收报告计数器（RC）：5比特，该SR包中的接收报告块的数目，可以为零。

包类型（PT）：8比特，SR包是200。

长度域（Length）：16比特，其中存放的是该SR包以32比特为单位的总长度减一。

同步源（SSRC）：SR包发送者的同步源标识符。与对应RTP包中的SSRC一样。

NTP Timestamp（Network time protocol）SR包发送时的绝对时间值。NTP的作用是同步不同的RTP媒体流。

RTP Timestamp：与NTP时间戳对应，与RTP数据包中的RTP时间戳具有相同的单位和随机初始值。

Sender’s packet count：从开始发送包到产生这个SR包这段时间里，发送者发送的RTP数据包的总数. SSRC改变时，这个域清零。

Sender\`s octet count：从开始发送包到产生这个SR包这段时间里，发送者发送的净荷数据的总字节数（不包括头部和填充）。发送者改变其SSRC时，这个域要清零。

同步源n的SSRC标识符：该报告块中包含的是从该源接收到的包的统计信息。

丢失率（Fraction Lost）：表明从上一个SR或RR包发出以来从同步源n(SSRC\_n)来的RTP数据包的丢失率。

累计的包丢失数目：从开始接收到SSRC\_n的包到发送SR,从SSRC\_n传过来的RTP数据包的丢失总数。

收到的扩展最大序列号：从SSRC\_n收到的RTP数据包中最大的序列号，

接收抖动（Interarrival jitter）：RTP数据包接受时间的统计方差估计

上次SR时间戳（Last SR,LSR）：取最近从SSRC\_n收到的SR包中的NTP时间戳的中间32比特。如果目前还没收到SR包，则该域清零。

上次SR以来的延时（Delay since last SR,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，全称Transfer Control Protocol，中文名为传输控制协议，它工作在OSI的传输层，提供面向连接的可靠传输服务。

TCP的工作主要是建立连接，然后从应用层程序中接收数据并进行传输。TCP采用虚电路连接方式进行工作，在发送数据前它需要在发送方和接收方建立一个连接，数据在发送出去后，发送方会等待接收方给出一个确认性的应答，否则发送方将认为此数据丢失，并重新发送此数据。

**2****、TCP****报头**

TCP报头总长最小为20个字节，其报头结构如下图（图1）所示；

比特0　　　　　　　　　　   比特15   比特16　　　　　　　      比特31

<table> 
 <tbody> 
 <tr> 
 <td colspan="3"> 源端口（16） </td> 
 <td style="vertical-align:top;"> 目的端口（16） </td> 
 </tr> 
 <tr> 
 <td colspan="4"> 序列号（32） </td> 
 </tr> 
 <tr> 
 <td colspan="4"> 确认号（32） </td> 
 </tr> 
 <tr> 
 <td> TCP偏移量（4） </td> 
 <td> 保留（6） </td> 
 <td> 标志（6） </td> 
 <td style="vertical-align:top;"> 窗口（16） </td> 
 </tr> 
 <tr> 
 <td colspan="3"> 校验和（16） </td> 
 <td style="vertical-align:top;"> 紧急（16） </td> 
 </tr> 
 <tr> 
 <td colspan="4"> 选项（0或32） </td> 
 </tr> 
 <tr> 
 <td colspan="4"> 数据（可变） </td> 
 </tr> 
 <tr> 
 <td>&nbsp;</td> 
 <td>&nbsp;</td> 
 <td>&nbsp;</td> 
 <td>&nbsp;</td> 
 </tr> 
 </tbody> 
</table>

（图1　TCP报头结构）

源端口：指定了发送端的端口

目的端口：指定了接受端的端口号

序号：指明了段在即将传输的段序列中的位置

确认号：规定成功收到段的序列号，确认序号包含发送确认的一端所期望收到的下一个序号

TCP偏移量：指定了段头的长度。段头的长度取决与段头选项字段中设置的选项

保留：指定了一个保留字段，以备将来使用

标志：SYN、ACK、PSH、RST、URG、FIN

SYN： 表示同步

ACK： 表示确认

PSH： 表示尽快的将数据送往接收进程

RST： 表示复位连接

URG： 表示紧急指针

FIN： 表示发送方完成数据发送

窗口：指定关于发送端能传输的下一段的大小的指令

校验和：校验和包含TCP段头和数据部分，用来校验段头和数据部分的可靠性

紧急：指明段中包含紧急信息，只有当U R G标志置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 三种协议的性能对比

<table> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;"> &nbsp; 协议名称 </td> 
 <td style="vertical-align:top;"> &nbsp; 复杂性 </td> 
 <td style="vertical-align:top;"> 连接建 立时间 </td> 
 <td style="vertical-align:top;"> &nbsp; 可靠性 </td> 
 <td style="vertical-align:top;"> 是否确保数据报发送和接受顺序 </td> 
 <td style="vertical-align:top;"> &nbsp; 实时性 </td> 
 <td style="vertical-align:top;"> &nbsp; 适用范围 </td> 
 <td style="vertical-align:top;"> 是否支持组播 &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> RTP/RTCP </td> 
 <td style="vertical-align:top;"> 低 </td> 
 <td style="vertical-align:top;"> 少 </td> 
 <td style="vertical-align:top;"> 低 </td> 
 <td style="vertical-align:top;"> 否 </td> 
 <td style="vertical-align:top;"> 是 </td> 
 <td style="vertical-align:top;"> 实时音视 频媒体传输 </td> 
 <td style="vertical-align:top;"> 支持 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> TCP </td> 
 <td style="vertical-align:top;"> 高 </td> 
 <td style="vertical-align:top;"> 多 </td> 
 <td style="vertical-align:top;"> 高 </td> 
 <td style="vertical-align:top;"> 是 </td> 
 <td style="vertical-align:top;"> 否 </td> 
 <td style="vertical-align:top;"> 数据和控制信令传输 </td> 
 <td style="vertical-align:top;"> 不支持 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> UDP </td> 
 <td style="vertical-align:top;"> 低 </td> 
 <td style="vertical-align:top;"> 少 </td> 
 <td style="vertical-align:top;"> 低 </td> 
 <td style="vertical-align:top;"> 否 </td> 
 <td style="vertical-align:top;"> 否 </td> 
 <td style="vertical-align:top;"> 音视频媒体传输 </td> 
 <td style="vertical-align:top;"> 支持 </td> 
 </tr> 
 </tbody> 
</table>

[UDP_TCP_RTP_ - super-and-star - super-and-star]: /images/20220404/06a6c7fdec2e480ba3e6f1cda94b34d2.png
[UDP_TCP_RTP_ - super-and-star - super-and-star 1]: /images/20220404/cd9ef500ff1c49bea43a956c2acb17ce.png
[UDP_TCP_RTP_ - super-and-star - super-and-star 2]: /images/20220404/52e9ec4edc784e97a47473c553c1df43.png
[UDP_TCP_RTP_ - super-and-star - super-and-star 3]: /images/20220404/bd7c6806e45b42aa9004920a13b9d124.png
[UDP_TCP_RTP_ - super-and-star - super-and-star 4]: /images/20220404/fac5923d5ac1411cbc620625def139f8.png