webrtc音频系列——4、RTP与RTCP协议

如果让你从0开发一套实时互动直播系统，你首先要选择网络传输协议。

UDP 还是 TCP？

答案是：UDP。

为什么实时传输不能用 TCP ？

TCP 的目的就是实现数据的可靠传输，因此他有一套 握手，发送 -> 确认，超时 -> 重发 的机制。

举个例子，A 与 B 通讯，A 首先向 B 发送数据，并启动一个定时器。当 B 收到 A 的数据后，B 需要给 A 回一个ACK（确认）消息，反复这样操作，数据就源源不断地从 A 流向了 B。如果因为某些原因，A 一直收不到 B 的确认消息会怎么办呢？当 A 的定时器超时后，A 将重发之前没有被确认的消息，并重新设置定时器。

在 TCP 协议中，为了避免重传次数过多，定时器的超时时间会按 2 的指数增长。也就是说，假设第一次设置的超时时间是 1 秒，那么第二次就是 2 秒，第三次是 4 秒……第七次是 64 秒。如果第七次之后仍然超时，则断开 TCP 连接。你可以计算一下，从第一次超时，到最后断开连接，这之间一共经历了 2 分 07 秒，是不是很恐怖？

如果遇到前面的情况，A 与 B 之间的连接断了，那还算是个不错的情况，因为还可以再重新建立连接。但如果在第七次重传后，A 收到了 B 的 ACK 消息，那么 A 与 B 之间的数据传输的延迟就达到 1 分钟以上。对于这样的延迟，实时互动的直播系统是根本无法接受的。

基于以上的原因，在实现实时互动直播系统的时候你必须使用 UDP 协议。

RTP 协议

我们现在已经决定好用UDP做实时语音。

我们以视频为例，在视频中，一个 I 帧的数据量是非常大的（假设要几十 K）。而以太网的最大传输单元是多少呢？ 1.5K，所以要传输一个 I 帧需要几十个UDP包。这几十个包传到对端后，还要重新组装成 I 帧，这样才能进行解码还原出一幅幅的图像。那么我必须要在包中，添加额外的标记才能够完成组装。这至少包括：

• 序号：用于标识传输包的序号，这样就可以知道这个包是第几个分片了。

• 起始标记：记录分帧的第一个 UDP 包。

• 结束标记：记录分帧的最后一个 UDP 包。

有了上面这几个标识字段，我们就可以在发送端进行拆包，在接收端将视频帧重新再组装起来了。

其实，这样的需求在很早之前就已经有了。因此就有了RTP协议。下面让我们来详细看一下 RTP 协议吧。一般情况下，在实时互动直播系统传输音视频数据流时，我们并不直接将音视频数据流交给 UDP 传输，而是先给音视频数据加个 RTP 头，然后再交给 UDP 进行传输。

RTP 协议规范图

RTP协议头各部分含义

知道了上面这些字段的含义后，下面我们还是来看一个具体的例子吧！假设你从网上接收到一组音视频数据，如下：

...

{V=2,P=0,X=0,CC=0,M=0,PT:98,seq:13,ts:1122334455,ssrc=2345},

{V=2,P=0,X=0,CC=0,M=0,PT:111,seq:14,ts:1122334455,ssrc=888},

{V=2,P=0,X=0,CC=0,M=0,PT:98,seq:14,ts:1122334455,ssrc=2345},

{V=2,P=0,X=0,CC=0,M=0,PT:111,seq:15,ts:1122334455,ssrc=888},

{V=2,P=0,X=0,CC=0,M=0,PT:98,seq:15,ts:1122334455,ssrc=2345},

{V=2,P=0,X=0,CC=0,M=0,PT:111,seq:16,ts:1122334455,ssrc=888},

{V=2,P=0,X=0,CC=0,M=0,PT:98,seq:16,ts:1122334455,ssrc=2345},

{V=2,P=0,X=0,CC=0,M=0,PT:111,seq:17,ts:1122334455,ssrc=888},

{V=2,P=0,X=0,CC=0,M=0,PT:98,seq:17,ts:1122334455,ssrc=2345},

{V=2,P=0,X=0,CC=0,M=0,PT:111,seq:18,ts:1122334455,ssrc=888},

{V=2,P=0,X=0,CC=0,M=0,PT:98,seq:18,ts:1122334455,ssrc=2345},

{V=2,P=0,X=0,CC=0,M=0,PT:111,seq:19,ts:1122334455,ssrc=888},

{V=2,P=0,X=0,CC=0,M=0,PT:98,seq:19,ts:1122334455,ssrc=2345},

{V=2,P=0,X=0,CC=0,M=0,PT:111,seq:20,ts:1122334455,ssrc=888},

{V=2,P=0,X=0,CC=0,M=1,PT:98,seq:20,ts:1122334455,ssrc=2345},

...

假设 PT=98 是视频数据，PT=111 是音频数据，seq 是序号 ，ts 表示时间戳 。 按照上面的规则很容易就能将视频帧组装起来。

RTCP 协议

实时传输控制协议(Real-time ControlProtocol，RTCP)是和 RTP一起工作的控制协议。在RTP会话期间，每个会话参与者周期性地向所有其他参与者发送RTCP控制信息包。

每个参与者周期性地发送RTCP控制信息包

RTCP功能

在使用 RTP 包传输数据时，难免会发生丢包、乱序、抖动等问题，下面我们来看一下使用的网络一般都会在什么情况下出现问题：

• 网络线路质量问题引起丢包率高；

• 传输的数据超过了带宽的负载引起的丢包问题；

• 信号干扰（信号弱）引起的丢包问题；

• 跨运营商引入的丢包问题 ;

WebRTC 对这些问题在底层都有相应的处理策略，但在处理这些问题之前，它首先要让各端都知道它们自己的网络质量到底是怎样的，这就是 RTCP 的作用。

RTCP 报文的种类

RTCP也是用UDP来传送的，但RTCP封装的仅仅是一些控制信息，因而分组很短，所以可以将多个RTCP分组封装在一个UDP包中。根据所携带的控制信息不同，RTCP信息包可分为RR（接收者报告包）、SR（源报告包）、SEDS（源描述包）、BYE（离开申明）和APP（特殊应用包）五类5类：

RTCP 有两个最重要的报文：RR 和 SR 。通过这两个报文的交换，各端就知道自己的网络质量到底如何了。

SR 报文

SR 报文各部分的含义

从上图中我们可以了解到，SR 报文分成三部分：Header、Sender info和Report block。

• Header 部分用于标识该报文的类型，比如是 SR 还是 RR。

• Sender info 部分用于指明作为发送方，到底发了多少包。

• Report block 部分指明发送方作为接收方时，它从各个 SSRC 接收包的情况。

通过以上的分析，你可以发现SR 报文并不仅是指发送方发了多少数据，它还报告了作为接收方，它接收到的数据的情况。当发送端收到对端的接收报告时，它就可以根据接收报告来评估它与对端之间的网络质量了，随后再根据网络质量做传输策略的调整。

原文https://zhuanlan.zhihu.com/p/94570212

★文末名片可以免费领取音视频开发学习资料，内容包括（FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs）以及音视频学习路线图等等。

见下方!↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓