webrtc QOS方法四.1(拥塞算法学习)

一、网图简介

webrtc QOS方法四.1(拥塞算法学习)_第1张图片

现在我们接入网络的方式有三种:手机4G/5G、WIFI、网线。三种接入方式在网络中的位置如上图所示。引起网络质量差的原因也有很多,比方说4G/5G、WIFI信号弱、wifi信道竞争、云营商限速、跨运营商节点带宽竞争、终端设备应用程序抢占带宽等。

其中跨运营商节点带宽竞争可以使用BGP网络解决,其他目前都没有一个完美的解决方案。

二、拥塞算法思想

拥塞算法实际上是解决不了上述所有的问题的,它的思想是假设我们所有设备都正常运行情况下,只是由于发送数据量不合理,导致路由缓冲区变大,网络延时升高,更严重的缓冲区满异常,造成丢包。

所以拥塞算法的中心思想是通过调节发送数据量,改善网络延时、丢包质量。那么理想情况下发送多大数据量是合理的呢?这里引入一个带宽时延积BDP参数。BDP参数想要探测的是独享网络情况下,RTT延时最小(路由器缓存数据量最小)时,能发送的最大带宽。如下图所示:

webrtc QOS方法四.1(拥塞算法学习)_第2张图片

数据量不能太小,否则带宽利用率不高;数据量也不能太大,否则路由缓存区变大,RTT延时变高。第三个图,是BDP的最佳状态。也就是说BDP是将链路填满而不造成中间设备缓存数据包最大数据容量。再多的数据包进来,只能被路由设备给缓存起来延迟投递。延迟投递会造成RTT升高,而投递成功率(Dilivery Rate)却没法上升(投递效率的上限是瓶颈带宽BtlBw)。吞吐率到达BDP才是链路的最优工作点。

但是实际应用中,我们是无法同时探测出最大带宽和最小延时两个参数的。

三、典型拥塞算法比较

拥塞算法 检测方法 控制方法 缺点
cubic 丢包检测 通过丢包检测,检测网络是否拥塞,调整发送码率 Cubic是Loss-Based拥塞控制算法,要等到链路的Buffer填满后发生丢包才会降窗退避缓解拥塞,更要命的是,随机偶发性的丢包(如中间的路由故障切换到备份设备导致部分包丢失等)也会被误判成“拥塞”造成窗口减半,传输速率的急剧下降。
gcc 丢包+延时检测 通过丢包和延时检测网络是否拥塞,调整发送码率 同样存在滞后性,并且在wifi信道竞争、APP内置程序抢占带宽场景下,持续避让,不是好的解决方案。
bbr

分别探测:最大带宽、最小RTT延时

BBR寻求工作于这个最优点:寻求在不排队的情况下,以瓶颈带宽的速率持续发包,保持数据包排满管道,以求获取最大的吞吐率BDP。 BBR属于抢占带宽模式,若是其他程序都使用cubic或者gcc这种退让机制,BBR很给力。但是当大家都使用BBR,网络就会持续惨烈。(目前这样理解,后续细啃算法,再更新)

目前没有哪种拥塞算法能解决所有网络问题,需要程序探测目前网络属于哪种丢包模型,选择比较合适的应对措施。

四、参考

cubic:

https://allen-kevin.github.io/2017/12/21/TCP%E6%8B%A5%E5%A1%9E%E6%8E%A7%E5%88%B6%E4%B9%8BCUBIC/

BBR:

https://cloud.tencent.com/developer/article/1482633

https://blog.csdn.net/dog250/article/details/52830576

https://www.jianshu.com/p/4c9360f265e7

你可能感兴趣的:(webrtc视频QOS方法汇总)