浅析低延迟直播协议设计：RTP/RTCP

声明：本文来自「又拍云主办的Open Talk——在线教育：技术让知识触手可及」的演讲内容整理。PPT、速记和现场演讲视频等参见“UPYUN Open Talk”官网。
嘉宾：王宇航，红点直播联合创始人&CTO。毕业于中国科学技术大学，风云直播创始团队成员，曾参与逆向Adobe Flash非公开加密网络协议RTMFP，负责设计实现百万同时在线的大规模视频弹幕系统。2013年联合创立红点直播，现负责团队管理、产品研发及架构设计等相关工作。
责编：钱曙光，关注架构和算法领域，寻求报道或者投稿请发邮件qianshg@csdn.net，另有「CSDN 高级架构师群」，内有诸多知名互联网公司的大牛架构师，欢迎架构师加微信qshuguang2008申请入群，备注姓名+公司+职位。

如今的直播市场非常火爆，有很多直播云服务的提供商可供产品选择。同时视频直播产品喷涌而出，比如大家耳熟能详的映客、YY，还有最近特别火爆的一直播。

基于TCP的协议延迟不够低

众所周知，直播中通用CDN大部分提供的是RTMP的方案以及HLS的方案。HLS在手机H5里面的兼容性非常好，而RTMP是Adobe的协议，它在延迟、稳定性和分发质量方面平衡得很不错。但是当涉及会议场景时，基于TCP的协议就不能完全满足我们的要求了。

假设在没有丢包的状态下，正常设定传输是一个流媒体，同样数据具有时效性，从而单位时间内产生的数据有一个固定的量。固定量的数据在TCP协议站上有什么问题？TCP协议设计的目标是为了最大化带宽的利用率。它在传输的过程中会衡量信道的宽度，认为其所要达到的效果应该是使用户尽可能的高效使用网络。丢包的状态下，协议栈做出非常严厉的惩罚，降低它认为信道的宽度，并认为用户已经最大化的利用了这个网络，会认为如果有丢包是用户发多了或者是网络出现了拥塞。通过发送数据的数量来减缓拥塞情况，最终让它再回归正常水平。比如丢下一个数据，TCP做了一次惩罚，使后面的数据只能向后推，这个时间就是延迟的起点。

由此可以了解对丢包的处理是网络协议对延迟影响最大的一个因素。可能有的协议或者有一些网络对丢包不在乎，有一个包能够到达目标地点就足够了，但并不是所有的协议都能这样。

RTP

RTP（Real-Time Protocol）协议涵盖所有实时相关的东西。可以支持实时数据端到端传输、载荷类型定义、为数据打上序号、时间校对以及分发监控等。它不能保证及时发送以及质量保证，比如让协议给用户发送一个数据，其不保证发送的时间以及数量。它也不保证送达，也没有时序，如发的顺序是12345，收到的顺序可以是54321。这个协议听上去几乎不能用，但是这样一个没支持太多东西的协议实际上也给我们一个空间，致使我们可以在此个基础上为它增加很多策略，如拥塞控制算法可以增加包括对于时序的处理和对于质量的处理。

RTP头

RTP协议的头，左上第一行是版本号，表示的是协议标准；第二行代表协议后面有没有追加空白，然后X表示这个头是不是有扩展，CC是一个数量，M和PT其中有8个比特，表示数据类型，可以自定义，其次是一个序号，一个时间戳；下面的SSRC是同步源的标识，它支持转发和混合器的结构，混合器结构的功能是把参与会议的多媒体混成一路，再转给其它的听众。

RTP网络样例

RTP组织网络的样例，共分为三个角色：一个是终端，可以理解为每一位参与者，参与者既可以说话，也可以听到其他与会者的内容；第二个是混合器，其最直观的体现在音频领域，可以将多人说的话混成一路，首先它的带宽减少了，同时时序自然对上，保持一致；第三个角色是一个转发器，即把以上流转出去。

如下图所示，E1和E2经过第一路混合器，转出来即为SSRC值，它的值发生了改变。但是原来如E1：17，CSRC会体现在后面。通过这样的网络，能够组建一个支持会议场景的内容分发，尤其是流媒体的实时传输。

RTCP

为弥补RTP的不足，或者RTP没有保证的东西，我们设置了额外的协议即RTCP。RTCP共有5个类型数据包：发送方报告、接收方报告、源描述、结束通知、远程调用方法。

在发送方报告中，发送者真正关心是数据发送量、丢失情况、数据到达时间以及网络过程中的抖动；

接收方的报告主要反应发送方数据质量的信息，RTP里包含序号，可以体现多少序号断的、未收到。其中涉及到抖动和RTT的概念。

抖动

抖动指的发送方发两个数据即A和B，第一秒发A，第二秒发B。对于接收方来说，比如接收方第三秒收到A，但不一定第四秒能够收到B，可能第五秒才收到B。发送方隔1秒发送数据，但是接收方那边差2秒，这2秒和1秒称之为抖动。通过以上事例，可以看出时延具有不确定性。可以通过以下的公式对抖动进行平滑处理。

RRT

RRT(Round-Trip Time)描述的是一个数据包从发送方发送到接收者，接收者给出反馈，反馈再回到发送方，这时发送方识别到的时间差就是往返时间。其中计算用到的量包括DLSR和LSR。DLSR是距离上一个发送报告的时间。接收者可以使用DLSR，帮助发送者利用返回之后的报告算出来往返时间。RTT更像工程师日常使用网络中的ping。

流媒体丢包处理方案

流媒体丢包一般有3种处理方案：重传、前向纠错、交叉传输。

重传

第一个策略是重传，很明确地丢什么数据重新传什么数据，不会浪费资源。

前向纠错（FEC，Forward Error Correction）

所谓前向纠错，其实是数据冗余，是解决丢包问题的主要方案之一。可以分成两种类型：多媒体无关的前向纠错和多媒体相关的。本文将主要介绍多媒体无关的前向纠错，它更多会用在网络上，同时该技术在存储领域也有应用。

在观看实时场景时，正常情况下若出现丢包，比如上述的重传，如果发送方想知道这个东西是否需要重传，需要依赖往返时间。重传非常依赖RTT值，RTT比较大，重传策略很难设计，因为不知道它是丢了，还是收到了但没有来得及反馈。同样的情况可以利用前向纠错的技术，很大程度上不依赖重传，尤其是在会议的状态下。因为它的延迟一般是在250毫秒的量级，该量级下，重传的效果并不会很理想。

• 分层数据保护

分层数据保护是前向纠错对于分层的方案。分层指的是数据包里面有不同重要程度的数据，对于不同程度的数据分段对它进行保护。

• FEC数据包

前向纠错的数据包是基于RTP标准上设计的。前面是RTP包头，后面是前向纠错的数据包的格式。

• FEC算法

FEC算法其中一个称之为异或。假如有4个数据，那么它们可以取4个异或值，其中每一个数据都可以由另外4个异或计算出来。还可以把ABCD和E想象成一个数据包，如果我们传输ABCD这四个数据包，第五个数据包传输的是E，这五个数据包可以丢失任何1个数据包。接收方收到数据之后，能够把它丢的数据恢复出来。前向纠错算法能处理的是连续数据里只丢1个包。同时丢失A和B，这个算法不能解决。

因此这给予我们更多的操作空间。我们把将参数想成数据包，里面包含5个参数即5个数据包。左边设8个方程，8个方程可以解出来该5个数据包的值，通过8个方程可以解出右边的一个结果。在传输数据的时候，额外的几个方程组，即冗余的数据。也就是说原来的数据传的是12345这5个数据。然后又额外传了C，假如这8个数据里面任意丢了三个数据C1、C2和C3，程序可以利用其他内容额外把它们恢复出来，这个逻辑就是纠错过程冗余，以及冗余可以在任意位置恢复出来的原因。该算法的好处是可以连续的丢数据，比如网络传输的时候，传1到10这样数据，这个时候我们使用冗余度是5，10个数据有5个是冗余的，既50%的冗余度。这5个数据当中我们任意丢失5个数据，接收方认为这个数据包是完成的，没有丢任何数据，不需要重传，也不需要多媒体相关的纠错法。网络传输过程当中，每次发出去的数据不需要等待重传的延迟，可以把冗余数据发送出去。对于接方来讲，在带宽可以接受的情况下，延迟仍然是最低的。

交叉传输

最后一个策略是交叉传输，我们日常看到多媒体可能是按照时序的，一个多媒体片断是由1到10组成。如果此过程当中有丢包，比如3456连续丢失，那么此次丢包的影响可能表现在视频播放出现停顿。若丢的是关键帧那么影响非常大，会导致后面一大片的花屏。因此当连续丢包对流媒体伤害特别大的情况下，可以采用交叉传输策略。1到10，原来是3个3个传，如123、456、789各传一次，那么现在可以改变传输策略，采用147、 280和369的传输策略，这样一组数据丢掉，实际丢失在流媒体中间穿插的数据，播放程序可以在几乎不失真的状态下把视频恢复出来。

数据包拥塞控制协议(DCCP)

上述提到的RTP协议不仅可以基于UDP协议，也可以基于TCP协议。只是大部分利用RTP协议的场景实际上是基于UDP协议的。DCCP是一个拥塞控制的策略，里面包含4项内容：首先是建立会话，像TCP的握手；第二是数据窗口，可能很多时候要处理一个数据序号的顺序和整合一些数据碎片；第三是反馈，ACK就是关于数据到达反馈；最后是拥塞控制。其中数据窗口、反馈还有拥塞控制是影响传输质量的关键。

数据窗口跟数据的时效性关系很大，使用TCP协议时大部分数据长度跟时间关系不是那么强。但是会议场景对时效性要求较高。数据窗口里面时间很难超过1秒，1秒以后的数据其实就已经不再有任何用处了。

在Ack里面，一般会有两个策略：一种是直接告诉发送方未收到的数据；另一种是有选择性的直接告知发送方收到的数据片断所处的碎片状态，让发送方根据自己的情况，有选择地重发一些数据，避免一些不必要的负担。

众所周知，关于TCP协议相关内容有很严格的拥塞控制措施，使用最大的带宽下TCP传输超延迟内容不是很友好。DCCP则为我们提供一个方案，让我们自己控制拥塞控制，传输延迟和数据质量，对此我们可以有一个很强的掌控力。