持续精进 | RTC 系统音视频传输弱网对抗技术
今天，你刘畊宏女孩了吗？
持续大热的“李佳琦女生”和近期大势的“刘畊宏女孩”都在证明着，直播行业依然热度不减。经过多年发展，直播已经衍生出了越来越丰富的玩法，比如连麦 PK、一起看等。而这些场景，都非常依赖 RTC 实时音视频技术的兴起。
疫情反复，很多人又进入了居家时刻。把生活和工作转向线上成为大家对抗“停摆”焦虑的解决方案。除了直播、语聊房等娱乐社交场景，还有线上课堂、视频会议，乃至线上问诊咨询。
在我们把娱乐、社交和生活的方方面面搬到线上的过程中，RTC 实时音视频技术迅速发展，不断打卡新应用，渗透新场景。
一体两面，当先进技术为线上场景带来巨大增长的同时，也面临用户越来越高的体验要求，更低延时、更高画质、更加顺畅。
这三个用户体验的影响因素，对应着的也是 RTC 的三大核心指标，即实时性、清晰度、流畅度。
三者之间，往往鱼与熊掌不可兼得。实时性要求较高的场景可能会牺牲清晰度来保障低延时；而清晰度要求高的场景则可能用一定的延时换取高质量的音视频数据。
但是，小孩子才做选择。为了做到“既要又要”，我们通常需要通过网络传输优化来追求更低的延时、更高的清晰度和流畅性。其中的大 BOSS 就是弱网，这是造成拥塞、丢包、延时抖动等影响用户体验问题的主要因素。
弱网对抗技术就是针对上述问题以及其他网络损伤问题的技术解决方案统称。本文分享 RTC 系统音视频传输弱网对抗技术概览。
关于 TCP/IP 传输层协议的选择
首先，简要介绍一下传输层协议。
传输层协议在 TCP/IP 分层协议中位于应用层之下，一般由操作系统内部提供实现，包括 TCP 和 UDP 两种协议。TCP 是面向连接的可靠传输协议，为数据传输的完整性和有序性提供了保障；UDP 是无连接的不可靠传输协议，数据传输的可靠性完全交由应用层处理。
实时音视频应用场景下，UDP 作为优先选择已经是业界广泛共识。原因主要包括以下几点：
- TCP 协议并非为音视频实时应用场景设计，其内部的拥塞控制和差错控制等机制为了可靠性和高吞吐量而导致延时的增加，在弱网环境下延时的恶化更为明显。ITU StandardG.114 对延时的定义是，端到端延时大于 400ms 时，用户的交互体验将受到明显的影响。
- TCP 的拥塞控制机制和差错控制机制位于操作系统内部实现，应用层无法优化，无法应对不同场景需求进行调整，严重缺乏灵活性。
- UDP 协议本身开销比 TCP 小，传输控制策略完全交由应用层来实现，具有足够的灵活性。
因此，本文后续讨论的弱网问题及相应的弱网对抗技术基于 UDP 协议以及运行在 UDP 之上的被音视频领域广泛应用的 RTP/RTCP 协议来讨论。
弱网主要问题及其对抗技术
音视频传输弱网问题简单来说就是指影响音视频通信用户体验的网络环境问题，主要指网络拥塞、网络丢包、抖动等问题。
这些问题是造成音视频卡顿、实时性不佳的主要原因。由于网络环境具有较强复杂性、异构性，上述的弱网问题在不同环境下的严重程度也有很大差异。如何保障用户在复杂网络环境下进行顺畅的沟通，一直是 RTC 领域关注的重点问题。
拥塞问题
当网络中传输的数据流量超过网络瓶颈容量，就会产生拥塞问题。
拥塞的直接影响是突发丢包或者突发抖动，如果不及时预测拥塞的发生，及时降低发送数据量，接收端将会出现卡顿、延时大、画质差等等问题。
对抗拥塞问题的主要方案是，通过设计拥塞控制算法对网络拥塞进行及时的探测，并从拥塞状态尽可能快地恢复，尽量降低对用户体验的影响。
拥塞控制算法的需求考虑
RFC8836 对实时交互式音视频应用的拥塞控制算法需求进行了较为全面的总结，简单概括如下：
- 延时：拥塞控制算法应该尽可能降低延时，尤其是算法本身引入的延时。与此同时仍然需要提供可用的带宽水平。
- 吞吐率：在相应场景下吞吐率应尽可能高。
- 公平性：拥塞控制算法应该能够和其他实时流量和 TCP 流量公平地共享链路带宽。
- 避免“饿死”：媒体流在与 TCP 流竞争中不应被“饿死”，也不能把 TCP 流“饿死”。
- 收敛速度：在媒体流启动阶段尽可能快地收敛到稳定状态。
- 网络支持：算法不应要求特殊网络特性支持。
- 稳定性：算法应该在媒体流变化时保持稳定，比如媒体流暂时的传输中断。
- 快速响应：算法应该快速响应网络环境的变化，比如瓶颈带宽变化、链路延时变化等。
综合上述需求，拥塞控制算法要解决的问题可归类为两个方面，一是如何快速准确地进行网络拥塞探测；二是采取适当的拥塞应对措施尽量避免拥塞以及尽可能快地从拥塞状态恢复。
拥塞探测算法
拥塞探测算法根据观测数据的差异可用分为两类：
基于丢包的算法（Loss-based）：通过丢包事件来检测网络拥塞。
基于延时的算法（Delay-based）：通过对延时的测量来判断网络拥塞。
对于实时音视频交互式应用，基于延时的算法是更优的选择，主要原因是基于延时的算法能够更早地发现网络拥塞，从而避免由于拥塞导致的丢包。
此外，基于丢包的算法往往为了探测链路容量而不断增加发送带宽，直至丢包事件发生。这种策略将导致无法控制的网络排队延时增长，尤其是网络节点的缓冲区较大时，甚至造成秒级延时的增长。
选择基于延时的算法要重点考虑需求总结中的避免“饿死”问题。基于延时的算法对延时增长相对要敏感，在与基于丢包的算法竞争网络资源时要采取适当的策略，相对公平地分享网络带宽资源。
基于延时的算法一般通过测量 RTT（round-trip time 往返延时）或者 OWD（one-way delay 单向延时）来判断拥塞。
RTT 测量比较直观，但是由于是测量双向延时的总体情况，因此反向的延时变化会对媒体流方向的网络拥塞判断造成干扰。OWD 延时观测则避免了这个问题。如下图所示：
OWD 通过观测发送间隔与接收间隔的变化来判断网络排队延时的状况。
拥塞应对措施
简而言之，拥塞应对措施就是根据网络当前的拥塞状况计算出合适的发送速率来控制媒体发送端的总发送速率。根据发送端所采取的其他弱网对抗策略，可能的速率调节手段包括调节音视频编码器速率、调节重传速率、调节 FEC 冗余度等，详见本文后续介绍。如果发送端是中间转发节点，则调节手段还包括 SVC 码流适配、大小流码流适配等，如下图所示：
典型拥塞控制框架
典型的拥塞控制算法框架如下图所示：
这是早期 Google 在其 WebRTC 框架中采用的拥塞控制框架。采用发送端和接收端混合控制模式，发送端采用基于丢包的算法，基本策略如下：
- 丢包率<2%，增加发送带宽 8%；
- 丢包率 2% ~ 10%，发送带宽保持不变；
- 丢包率>10%，降低发送带宽（1-0.5*丢包率）。
接收端采用基于延时的算法。通过统计单向延时变化并通过卡尔曼滤波对当前的传输延时进行估计，再结合当前的实际接收带宽评估一个最佳的目标带宽，通过 RTCP 消息反馈给发送端。发送端取两个算法结果的最小值作为最终的目标带宽。
下图是 WebRTC 改进后的拥塞控制框架。
我们可以看到整个拥塞控制机制都在发送端实现，接收端只是反馈相应的测量数据。
新的框架改进了网络延时估计算法，通过对单向延时变化数据进行线性回归分析，评估当前网络排队延时变化趋势，即判断出延时正在增加、没有变化、正在降低三种趋势，再结合当前发送速率，给出最佳目标带宽估计。
除了改进拥塞探测算法，新的框架也引入了主动带宽探测机制，优化了整个拥塞控制算法的性能，经过比较，在启动阶段收敛速度、网络环境变化的响应速度上都有比较明显的改进。
丢包问题
如前所述，实时交互式媒体传输基于 RTP/UDP 协议，丢包问题由应用层处理。
网络传输方面（即信道侧）的抗丢包技术手段主要包括重传（ARQ）、前向纠错（FEC）。信源编码方面根据数据以及编码方的不同也可以提供某些特定的抗丢包能力，比如视频编码中采用 B 帧降低丢包的影响。下面主要介绍网络传输方面的抗丢包技术。
丢包重传（ARQ）
在 RTP/RTCP 协议中，丢包重传技术简单来讲就是接收端根据包序列号的连续性判断是否丢包，通过向源端发送 RTCP 中的 NACK 请求，要求源端重传指定的数据包。丢包重传流程如下图所示：
重传流程有以下细节需要考虑：
- 首次请求延时：应结合其他策略考虑发现丢包时是否立即请求，比如结合 FEC 策略考虑。
- 重复请求间隔考虑：同一个数据包重复请求间隔要大于当前 RTT。
- 请求次数限制：结合当前 RTT 与容忍的最大延时来计算。
- 发送端重传带宽限制：重传带宽作为总传输带宽的一部分，不能超出总体带宽限制。
- 重传包回传机制：建议采用单独的 RTP 码流发送，利于丢包率统计与重传带宽计算。
前向纠错（FEC）
在实时音视频应用中，前向纠错（FEC）技术在抗丢包方面因其实时性好而被广泛应用。
FEC 的基本思路粗略来讲就是发送端在发送音视频数据包之外，根据具体丢包状况再额外发送一定量的冗余数据包用于接收端进行丢包恢复，基本流程如下图所示：
目前常用的关于修复数据包的编码算法有基于异或的算法、基于矩阵的算法以及其他算法，本文不做详细阐述。
下面介绍一下 FEC 在实时音视频系统中的基本应用框架，发送端应用框架如下图所示：
上图中的 ADU 为应用数据单元，在音视频 RTC 系统中也就是音视频数据包，作为源数据块输入到 FEC 编码器，FEC 编码器根据一定的修复比率产生 FEC 修复包（repair payloads），修复包和源包及其之间保护关系一起发送给接收端。
接收端的 FEC 处理框架如下图所示：
接收端收到 FEC 源包和修复包后送到 FEC 解码器。如果源包丢失，解码器根据包组的保护关系以及收到的包组状况进行解码修复，最后将修复完成的音视频包交由上层进一步处理，完成音视频解码与显示播放。
上述中的修复包与源包的保护关系简而言之就是哪些源包被哪些修复包保护，这个保护关系由发送端通过一定的封包格式通知到接收端。
在 RTP/RTCP 协议框架下，ULPFEC（RFC5109）和 FlexFEC（RFC8627）两个标准定义了两种不同的策略和包格式：
ULPFEC：ULP（Uneven Level Protection，不均等保护）根据数据包重要程度使用不同级别的保护策略。
FlexFEC：Flexible Forward Error Correction，此标准在 RTP 协议框架下定义了交织与非交织的奇偶校验 FEC 编码包格式。
ARQ 与 FEC 的配合
相较于 FEC，ARQ 的缺点是会引入延时，优点是有较高的带宽利用率。抗丢包技术的优化目标概括来讲就是在满足延时要求的前提下，尽量以最小的额外带宽与计算成本，获得足够的保护力度。
因此，在考虑 ARQ 与 FEC 的配合策略时应考虑以下原则：
- 在延时限制容许的前提下尽可能使用 ARQ，可根据当前 RTT 和最大延时限制计算最大重传次数；
- 如果最大重传次数可以将丢包率降低到一定程度以下（<%1)，则不必开启 FEC 保护；
- 如果需开启 FEC，FEC 的保护程度要依据应用 ARQ 修复之后剩余的丢包概率来计算，进行兜底保护。
下图是在一定场景下的 FEC 与 ARQ 配合示意图，RTT 在 20ms 内，如果传输延时要求在 100ms 以内，在丢包 30% 的弱网链路上，则 ARQ 可以将丢包率降低到 1% 以下，则由 ARQ 负责丢包修复。
随着 RTT 的上涨，FEC 的保护占比增加，最终由 FEC 单独负责丢包修复。
抖动问题
概括而言，抖动问题就是网络传输延时变化问题，抖动越大表示网络传输延时变化越大。
抖动问题会造成接收端卡顿、播放快进等严重影响音视频沟通体验的问题。造成抖动问题的原因是多方面的，比如新的流加入造成网络资源竞争加剧、源端数据发送速率本身不平稳以及其他网络原因。
目前处理抖动的通用策略是接收端建立抖动缓冲区(JitterBuffer)来消除抖动，其原理如下图所示：
接收端通过增加抖动延时（JitterDelay）来吸收不均匀的延时，达到均匀播放的目的。
其中，抖动延时大小的计算是抖动缓冲区性能好坏的关键，过大的抖动延时会引入额外延时，这在实时交互式应用领域是极力要避免的；过小又无法吸收全部的抖动。
关于抖动延时的估计，Google 在其 WebRTC 框架中用了两种方法，在音频抖动处理中用直方图加遗忘因子的方式进行估计，如下图所示：
WebRTC 的音频抖动延时估计在其内部的 NetEQ 模块中，图中的 Iat 意为间隔达到时间，WebRTC 通过对音频包到达间隔用直方图进行统计，取 95 分位数的延时时长作为音频抖动延时。
为了跟踪延时变化，NetEQ 中采用遗忘因子对直方图中的历史数据进行遗忘。当然，NetEQ 所提供的是一个综合的音频 QoS 保障技术，还有许多其他的技术参与处理音频抖动，如峰值抖动检测、语音变速等，这里不再详述。
视频抗抖动方面，WebRTC 采用不同于音频的抖动延时估计算法，通过对实际的帧尺寸变化与延时变化数据的测量与统计，利用卡尔曼滤波器动态地进行最优抖动延时估计。
然而，WebRTC 主要为一对一实时沟通的应用场景设计，在如视频会议等一对多、多对多场景下，音视频流更多的是通过流媒体中转服务转发。通过实测，该算法对多节点转发场景下的全链路抖动延时估计效果有待改进。
融云的弱网对抗技术优化实践
融云的优化措施
- 拥塞控制方面，基于 Google GCC 算法进行改进。除了统计单向延时变化进行拥塞趋势判断之外，同时对丢包模式进行进一步分析，提升带宽预测的准确率。
- 抗丢包方面，基于 FlexFEC 框架，采用高修复能力的 FEC 编码，并进行综合调优来提升抗丢包能力。
- 优化 ARQ 与 FEC 机制的配合，力求抗丢包付出的代价最小。
- 抗抖动方面，采用场景适应性更强的抖动延时估计方法，力求提升流畅度的同时减少延时。
部分结果
下图展示了目前高丢包场景下弱网抗性测试结果。
在 60%、70% 的高丢包场景下，Android 和 iOS 移动端测试结果在流畅度方面 MOS 值仍可以达到 4 分。
在具体弱网优化过程中，由于网络的复杂性、异构性，以及场景需求的多样性，实时音视频传输策略与弱网对抗技术充满着各种选择、平衡与取舍的考量，新的基于在线学习、强化学习的技术思路也在该领域开始进行尝试。
我们也将继续探索实践，为提升融云实时音视频 RTC 产品的综合用户体验而不断努力。
在社交产品花样繁多、玩法创新的当下，融云 IM 即时通讯不仅拥有强大的历史积累优势，同时在新社交形态频出的当下依然引流行业，永葆创新力和生命力。点击下方链接⬇️，快来体验吧～