【原创】WebRTC的拥塞控制技术(Congestion Control)

144 
作者 qiuyi943 
2016.09.07 23:40 字数 2734 阅读 695评论 1
本文为个人原创,欢迎转载,但请务必在明显位置注明出处!

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

 WebRTC

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!

赞赏支持

没有更多推荐了,返回首页