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

一、网图简介

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

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

二、拥塞算法思想

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

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

数据量不能太小，否则带宽利用率不高；数据量也不能太大，否则路由缓存区变大，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