13. UDP协议与RTP协议

本文主要是介绍13. UDP协议与RTP协议，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

UDP协议

UDP协议比较简单：

UDP的长度是固定的，用总长度-UDP长度就是数据长度。
UDP是不保证他的有序性和可靠性的。对于音频和视频是这样是比较好的，因为这段丢了，我们可以从下一段在开始解码。

RTP

RTP 协议概述

RTP（Real-time Transport Protocol）是用于 Internet 上针对多媒体数据流的一种传输层协议，RTP 协议和 RTP 控制协议 RTCP 一起使用。RTP 被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP 的典型应用建立在 UDP 上，但也可以在 TCP 或 ATM 等其他协议之上工作。

RTP 不像 http 和 ftp 可完整的下载整个影视文件，它是以固定的数据率在网络上发送数据，客户端也是按照这种速度观看影视文件，当影视画面播放过后，就不可以再重复播放，除非重新向服务器端要求数据。

RTP 本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠 RTCP 提供这些服务。

RTP 工作机制

rtp 协议就是提供了时间标签，序列号以及其它的结构用于控制适时数据的流放。在流的概念中” 时间标签” 是最重要的信息。发送端依照即时的采样在数据包里隐蔽的设置了时间标签。在接受端收到数据包后，就依照时间标签按照正确的速率恢复成原始的适时的数据。不同的媒体格式调时属性是不一样的。

但是 rtp 本身并不负责同步，rtp 只是传输层协议，为了简化运输层处理，提高该层的效率。 将部分运输层协议功能（比如流量控制）上移到应用层完成。同步就是属于应用层协议完成的。它没有运输层协议的完整功能，不提供任何机制来保证实时地传输数据，不支持资源预留，也不保证服务质量。rtp 报文甚至不包括长度和报文边界的描述。同时 rtp 协议的数据报文和控制报文的使用相邻的不同端口，这样大大提高了协议的灵活性和处理的简单性。

rtp 协议和 udp 二者共同完成运输层协议功能。udp 协议只是传输数据包，不管数据包传输的时间顺序。rtp 的协议数据单元是用 udp 分组来承载的。在承载 rtp 数据包的时候，有时候一帧数据被分割成几个包具有相同的时间标签，则可以知道时间标签并不是必须的。而 udp 的多路复用让 rtp 协议利用支持显式的多点投递，可以满足多媒体会话的需求。

RTP 协议的报文结构

每一个 RTP 数据报都由头部（Header）和负载（Payload）两个部分组成，其中头部前 12 个字节的含义是固定的，而负载则可以是音频或者视频数据。

RTP 头格式如图所示：

开始 12 个八进制出现在每个 RTP 包中，而 CSRC 标识列表仅出现在混合器插入时。各段含义如下：

1. 版本（V）
   2 位， 标识 RTP 版本。

2. 填充标识（P）
   1 位，如设置填充位，在包尾将包含附加填充字，它不属于有效载荷。填充的最后一个八进制包含应该忽略的八进制计数。某些加密算法需要固定大小的填充字，或为在底层协议数据单元中携带几个 RTP 包。

3. 扩展（X）
   1 位，如设置扩展位，固定头后跟一个头扩展。

4. CSRC 计数（CC）
   4 位，CSRC 计数包括紧接在固定头后 CSRC 标识符个数。

5. 标记（M）
   1 位，标记解释由设置定义，目的在于允许重要事件在包流中标记出来。设置可定义其他标示位，或通过改变位数量来指定没有标记位。

6. 载荷类型（PT）
   7 位，记录后面资料使用哪种 Codec ，receiver 端找出相应的 decoder 解码出来
   

7. 序列号
   16 位，序列号随每个 RTP 数据包而增加 1，由接收者用来探测包损失。序列号初值是随机的，使对加密的文本攻击更加困难。TCP也是有一个sequence number的，TCP中的sequence number通过ACK进行回复的，以达到排序的效果。

8. 时间戳
   32 位，时间戳反映 RTP 数据包中第一个八进制数的采样时刻，采样时刻必须从单调、线性增加的时钟导出，以允许同步与抖动计算。时标可以让 receiver 端知道在正确的时间将资料播放出来。
   
   由上图可知，如果只有序列号，并不能完整按照顺序的将 data 播放出来，因为如果 data 中间有一段是没有资料的，只有序列号的话会造成错误，需搭配上让它知道在哪个时间将 data 正确播放出来，如此我们才能播放出正确无误的信息。

9. SSRC
   32 位，SSRC 段标识同步源。此标识不是随机选择的，目的在于使同一 RTP 包连接中没有两个同步源有相同的 SSRC 标识。尽管多个源选择同一个标识的概率很低，所有 RTP 实现都必须探测并解决冲突。如源改变源传输地址，也必须选择一个新 SSRC 标识以避免插入成环行源。

10. CSRC 列表
    0 到 15 项，每项 32 位。CSRC 列表表示包内的对载荷起作用的源。标识数量由 CC 段给出。 如超出 15 个作用源，也仅标识 15 个。CSRC 标识由混合器插入，采用作用源的 SSRC 标识。
    RTP 用到的地方就是 PLAY ，服务器往客户端传输数据用 UDP 协议，RTP 是在传输数据的前面加了个 12 字节的头(描述信息)。

RTP 载荷封装设计本文的网络传输是基于 IP 协议，所以最大传输单元(MTU)最大为 1500 字节，在使用 IP/UDP/RTP 的协议层次结构的时候，这其中包括至少 20 字节的 IP 头，8 字节的 UDP 头，以及 12 字节的 RTP 头。这样，头信息至少要占用 40 个字节，那么 RTP 载荷的最大尺寸为 1460 字节。以 H264 为例，如果一帧数据大于 1460，则需要分片打包，然后到接收端再拆包，组合成一帧数据，进行解码播放。

实时传输 TCP/UDP协议的选择

当网络很卡的时候，他的实时性是不能保证的。比如说客户端给服务器端发送一个，等到1s还没有收到sck。下次也是那么这个TCP的实时性是不能保证的。TCP虽然可以保证包的有序可靠到达，但是代价失去了实时性。尤其是在极端情况下。
所以我们需要选择UDP，但是UDP需要解决丢包，乱序，这些都要在应用层解决。这也就是我们为什么都使用WebRTC，因为这些事情他都帮你解决了。

TCP在实时通信的作用

当UDP不通的时候可以使用TCP,比如说跟国外的人进行通讯，这时候UDP不行，可以使用TCP来保证联通率。因为企业级的通讯软件他的连通率要达到99%以上。如果TCP也不通的话，就用https，https底层也是TCP和一些安全的机制。
也就是一开始用UDP，如果UDP不通的话，就用TCP，TCP也不通的话就用https。
用TCP和https就是为了增加连通率。

这篇关于13. UDP协议与RTP协议的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---