WebRTC的拥塞控制和带宽策略

网络的波动带来的卡顿直接影响着用户的体验，在WebRTC中设计了一套基于延迟和丢包反馈的拥塞机制（GCC）和带宽调节策略来保证延迟、质量和网路速度之间平衡，本文中重点是介绍基于trendline滤波的评估模型。

在视频通信的技术领域WebRTC已成为主流的技术标准，WebRTC包涵了诸多优秀的技术，譬如：音频数字信号处理技术（AEC, NS, AGC）、编解码技术、实时传输技术、P2P技术等，这些技术目的都是为了实现更好实时音视频方案。但是在高分辨率视频通信过程中，通信时延、图像质量下降和丢包卡顿是经常发生的事，甚至在WiFi环境下，一次视频重发的网络风暴可以引起WiFi网络间歇性中断，通信延迟和图像质量之间存在的排斥关系是实时视频过程中的主要矛盾。

分析WebRTC是如何解决这个矛盾之前，先来看看我们在在线教育互动的生产环境统计到的视频延迟和人感官的关系，大致如下：

也就是说，通信过程中最好将视频延迟控制在800毫秒以内。除了延迟，视频图像质量也是个对人感官产生差异的关键因素，我们以640x480分辨率每秒24帧的H264编码情况下视频码率和人感官之间的关系（这组数据是我们通过小范围线上用户投票打分的数据）：

从上面的描述可以知道视频质量保持在一个可让人接受的质量范围是需要比较大的带宽码率支持的，如果加上控制延迟，则更需要网络有很好速度和稳定性。但是很不幸，我们现阶段的移动网络和家用WiFi并不是我们想象中的那么好，很难做到在实时视频通信中一个让人非常满意的程度。为了解决以上几个问题，WebRTC设计了一套基于延迟和丢包反馈的拥塞机制（GCC）和带宽调节策略来保证延迟、质量和网路速度之间平衡，这是一个持续循环过程，如下图：

图1：拥塞控制循环示意图

1） estimator通过RTCP的feedback反馈过来的包到达延迟增量和丢包率信息计算出网络拥塞状态并评估出适合当前网络传输的码率，根据这个码率改变视频编码器码率，然后改变pacer的码率

2） pacer会根据这个码率改变pacer的网络发送速度和padding比例，并用新的网络发送速度来定时触发发包事件。

3） sender收到pacer的发送事件，进行RTP报文发送。

4） receiver接收到RTP报文，进行arrival time统计和丢包统计

5） feedback定时对receiver统计的信息进行RTCP编码，并反馈到发送端的estimator进行新一轮的码率评估。

以上是整个WebRTC拥塞控制和带宽调节过程，下面这个示意图是这个过程涉及到WebRTC内部模块关系。

图2：WebRTC的拥塞控制模块关系图

需要说明的是红框中基于接收端的kalman filter带宽评估模型已经在新版本的WebRTC中不采用了，只做了向前版本兼容，新版本的WebRTC都是采用发送端的trendline滤波器来做延迟带宽评估，本文中重点是介绍基于trendline滤波的评估模型，下面依次来分析WebRTC的这五个过程。

1 estimator

estimator的功能就是通过接收端反馈过来的包到达时刻信息、丢包信息和REMB信息进行当前网络状态的码率评估，WebRTC拥塞控制有两部分：基于延迟的拥塞控制和基于丢包的拥塞控制，它是一个尽力而为的拥塞控制算法，牺牲了拥塞控制的公平性换取尽量大的吞吐量。从设计结构来描述向它输入延迟和丢包信息，它就会输出一个适应当前网络状态的码率值。示意图如下：

图3：WebRTC的CC estimator输入与输出

从上图可以看出，estimator基于延迟的拥塞控制是通过trendline滤波再进行过载判断，最后根据过载情况进行aimd码率调控评估出一个bwe bitrate码率，这个码率会合丢包评估出来的码率和remb来决定最后的码率。

1.1 基于延迟的拥塞控制

基于延迟的拥塞控制是通过每组包的到达时间的延迟差（delta delay）的增长趋势来判断网络是否过载，如果过载进行码率下调，如果处于平衡范围维持当前码率，如果是网络承载不饱满进行码率上调。这里有几个关键技术:包组延迟评估、滤波器趋势判断、过载检测和码率调节。

1.1.1 包组与延迟

WebRTC在评估延迟差的时候不是对每个包进行估算，而是采用了包组间进行延迟评估，这符合视频传输（视频帧是需要切分成多个UDP包）的特点，也减少了频繁计算带来的误差。那么什么是包组呢？就是距包组中第一个包的发送时刻t0小于5毫秒发送的所有的包成为一组，第一个超过5毫秒的包作为下一个包组第一个包。为了更好的说明包组和延迟间的关系，先来看示意图：