zoukankan      html  css  js  c++  java
  • 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

  • 相关阅读:
    dubbo入门(一)
    java中文件操作《一》
    Unity 游戏框架搭建 2019 (七) 自定义快捷键
    凉鞋:我所理解的框架 【Unity 游戏框架搭建】
    Unity 游戏框架搭建 2019 (六) MenuItem 复用
    Unity 游戏框架搭建 2019 (五) 打开所在文件夹
    Unity 游戏框架搭建 2019 (四) 导出 UnityPackage
    Unity 游戏框架搭建 2019 (三) 生成文件名到剪切板
    Unity 游戏框架搭建 2019 (二) 文本复制到剪切板
    Unity 游戏框架搭建 2019 (一) 简介与第一个示例文件名的生成
  • 原文地址:https://www.cnblogs.com/wainiwann/p/6678401.html
Copyright © 2011-2022 走看看