WebRTC的拥塞控制技术<转>

转载地址：http://www.jianshu.com/p/9061b6d0a901

1. 概述

对于共享网络资源的各类应用来说，拥塞控制技术的使用有利于提高带宽利用率，同时也使得终端用户在使用网络时能够获得更好的体验。在协议层面上拥塞控制是TCP的一个总要的组成部分；但是对于非面向链接的传输层协议，如UDP，其在协议层面上并没有对拥塞控制进行强制性的要求，这样做保证了最优的传输性能，且在拥塞控制的设计上也保留了更大的灵活性。

WebRTC为我们提供了强大的音视频媒体引擎，前端开发者可以通过调用几个简单的js接口就能实现基于Web浏览器的实时音视频通信。而在媒体数据传输上，WebRTC采用了实时性较强UDP协议，并使用了RTP/RTCP技术。本文的主要内容就是介绍WebRTC中基于RTP/RTCP实现的拥塞控制技术。

---

2. 拥塞控制算法

WebRTC采用了两种拥塞控制算法：（1）基于延迟（delay-based）的拥塞控制算法；（2）基于丢包（loss-based）的拥塞控制算法。算法（1）由数据的接收方实现，接收方需要记录每个数据包到达的时间和大小，并计算每个数据分组之间（inter-group）的延迟的变化，由此判断当前网络的拥塞情况，并最终输出码率估计值由RTCP feedback（TMMBR或 REMB）反馈给发送方；算法（2）则由数据的发送方来实现，发送方通过从接收方周期性发来的RTCP RR（Receiver Report）中获取丢包信息以及计算RTT，并结合TMMBR或REMB中携带的码率信息算得最终的码率值，然后由媒体引擎根据码率来配置编码器，从而实现码率的自适应调整。从上面的描述可以看出，这两个算法在系统中并不是孤立存在的。

拥塞控制算法时序图.png

2.1 基于延迟（delay-based）的拥塞控制算法

基于延迟的拥塞控制算法可以分成以下4个部分：（1）到达时间模型（arrive-time model）;（2）预过滤（Pre-filtering）；（3）到达时间滤波器（arrive-time filter）；（4）过载检测器（over-use detector）。

基于延迟的拥塞控制算法.png

2.1.1 到达时间模型（arrive-time model）

设相邻两个数据分组到达接收方的时间间隔为t(i) - t(i-1)，而两者被发送的时间间隔则为T(i) - T(i-1)，那么就有延迟变量d(i)=t(i)-t(i-1) - (T(i)-T(i-1))。如果d(i) > 0，就说明数据在网络传输时存在延迟的现象。

在WebRTC中延迟变量d(i) = w(i)被视为随机过程W中一个采样点，并且是链路承载能力、网络当前传输状况以及当前发送速率等因素综合作用的结果。该随机过程W符合正态分布。当网络发生过载（over-use）时，我们期望w(i)会上升；当网络空闲（Under-use）时，则期望w(i)会下降。

测量方程进一步改写为 d(i) = m(i) + v(i)，其中m(i)符合均值为0的正态分布（标准正态分布），v(i)表示为网络抖动等因素带来的对数据延迟的影响。

2.1.2 预过滤（Pre-filtering）

预过滤的目的是处理由于通道中断造成的延迟瞬间变大的情况。在通道发生中断时，数据包会持续进入网络队列中，而当通道恢复时，所有的数据包会在一个burst时间（5 ms）里面全部发送，而这些数据包可能原先包分布于多个数据分组。而预过滤所要做的就是将这些在同一个burst时间里发送的数据包合为一个数据分组。

这里涉及到了WebRTC中关于数据传输的一个设计--PacedSender。Encoded数据完成RTP封装之后先是被保存在本地应用的队列中，而不是直接发送到网络。此时可以将PacedSender视为一个数据发送的节拍器，它每隔一个burst时间启动一次，启动之后会将队列中的RTP包全数发出。

数据包会在下面两种情况下被划分到一个数据分组：

• 在同一个burst时间区间内被发送的数据包序列；
• 一个数据包与相邻数据包的到达时间间隔小于一个burst时间，同时d(i) < 0，那么这个数据包将会被划到当前的分组中。

2.1.3 到达时间滤波器（arrive-time filter）

在此系统希望通过预测m(i)来检测当前的网络是否过载；而这里所采用的预测方法是卡尔曼滤波（Kalman filter）。
状态方程：m(i+1) = m(i) + u(i)， 其中u(i)表示为状态噪声，符合0均值正态分布。
测量方程：d(i) = m(i) + v(i)， 其中v(i)表示为测量噪声，符合0均值正态分布。
卡尔曼滤波器根据“5组公式”来迭代更新m(i) 的估计值m_hat(i)，该估计值m_hat(i)则是下文过载检测器的检测依据。关于卡尔曼滤波器如何实现预测的详细介绍在这里就不做展开了，可参考文献[3]。

2.1.4 过载检测器（over-use detector）

通过Kalman 滤波器能够获得延迟变量m(i)的估计值，而过载检测器的工作原理其实就是通过m(i)与阈值del_var_th进行比较来对当前的网络拥塞状况进行检测。如果m(i) > del_var_th且m(i) > m(i-1)，同时该状态至少持续了overuse_time_th毫秒，则判断为网络过载（Over-use）；如果m(i) < -del_var_th，则判断为网络空闲（Under-use）；剩余的情况都被判断为Normal状态。

由此可见，阈值del_var_th的设计对于整个算法的性能来说至关重要。如果del_var_th的值设得过大，那么整个算法的动态就会显得过于平滑，此时只有在数据分组严重delay时检测器才会触发over-use的信号；相反的，如果del_var_th的值设得过小，那么检测器就会对delay非常敏感，从而导致频繁触发over-use信号。因此，WebRTC提出了针对阈值del_var_th的动态调整算法：

del_vat_th(i) = del_var_th(i-1)+ (t(i) - t(i-1)) * K(i) * (|m(i)| - del_var_th(i-1))

其中，当|m(i)| < del_var_th(i-1)时K(i)=K_d；否则，K(i)=K_u。

在WebRTC中本小节所涉及的各参数的参考值如下：
del_var_th(0) = 12.5 ms, overuse_time_th = 10 ms, K_u=0.01, K_d=0.00018

2.1.5 速率控制（rate control）

速率控制子系统根据当前网络的拥塞情况（由过载检测器提供），计算带宽估计值并请求发送方对速率进行调整。该子系统通过有限状态机对速率进行自适应调整。其状态迁移如下图所示：

速率控制状态机.png

• 状态 Increase： 表明当前没有检测到网络拥塞，在此状态下传输速率需要逐步增加；它先是通过乘性增加来调整速率（乘性因子为1.08），当速率接近临界值时再通过加性增加逐步收敛，而这里所谓的临界值是指上一次在状态Decrease 时统计的下行码率；
• 状态 Decrease： 表明当前检测到了网络拥塞，在此状态下传输速率需要逐步下降；在这里，WebRTC所采用的方法是乘性下降，其乘性因子为0.85；
• 状态 Hold： 表明保持当前的速率不做改变。

速率控制子系统最终会输出一个带宽估计值A_hat，并通过RTCP Feedback（TMMBR/REMB）请求发送方进行速率调整。

2.2 基于丢包（Loss-based）的拥塞控制算法

基于丢包的拥塞控制是通过对丢包率，RTT和带宽估计值A_hat这三个参数进行决策而实现的。其中带宽估计值A_hat正是由上节中的速率控制子系统所提供。

基于丢包的拥塞控制在每次收到对方发送RTCP之后都会运行：

• 当丢包率保持在[2%, 10%]时，当前数据发送方的带宽估计值As_hat保持不变；
• 当丢包率大于10%时，带宽估计值将会降低：As_hat(i) = As(i-1)*(1-p)，其中p为丢包率；
• 当丢包率小于2%时，带宽估计值将会上升：As_hat(i) = As(i-1)*1.05。

As_hat更新之后将与A_hat进行比较，然后取两者中的较小值作为最终的带带宽估计值。

其实在原生的代码中，系统还会将丢包率和RTT作为参数，通过TFRC [RFC 5348]的吞吐率计算公式对当前的带宽进行估计，而最终的估计值则是取三者中的最小值。

---

3. 后语

通过上文的介绍，我们知道WebRTC中的拥塞控制算法还是非常完备的。其分别针对数据包的延迟和丢包设计了delay-based和loss-based拥塞控制算法，在两者的共同作用之下，WebRTC能够满足大部分场景下的实时视频通话业务。但是，如果有要对WebRTC中的媒体引擎进行移植的朋友，首先要分析一下WebRTC的拥塞控制算法是否满足你的业务需求：如果是开发独立应用，由于业务闭环，直接使用现有的算法应该问题不大；但是，如果是用于开发提供类似VoLTE/VoWIFI这样的运营商增值服务的应用，需要依据运营商的技术手册和3GGP协议等来对拥塞控制算法进行适配。

Reference
[1] A Google Congestion Control Algorithm for Real-Time Communication draft-ietf-rmcat-gcc-02
[2] RFC 5348
[3] http://blog.csdn.net/xiahouzuoxin/article/details/39582483
[4] 3GPP TS 26.114