TCP BBR算法的带宽敏感性以及高丢包率下的优化

分享一下我老师大神的人工智能教程。零基础！通俗易懂！风趣幽默！还带黄段子！希望你也加入到我们人工智能的队伍中来！https://blog.csdn.net/jiangjunshow

                bbr算法比较简单也比较容易理解，所有关于它的优化也就同样不复杂了。
        请注意，任何优化都只针对特定场景的，根本不存在一种放任四海而皆准的算法。我们分析Google的测试报告时，比较容易被忽视的是其bbr算法的部署场景。如果可以完美复现Google的B4网络，那么测试结果应该就跟Google是一致的，但不得不说，bbr算法内置了很多的参数(目前的版本中是写死的)，Google方面有没有调整这些参数是未知的。我们先看一下bbr算法是怎么利用空余带宽的。
        bbr算法最终会稳定在Steady-state，即其PROBE_BW的状态，该状态内置了一个小循环，bbr在这个循环中不停运转：

注意其中的速率增益：1|1|1|1|1|1|1.25|0.75|1|1|1|1|1|1|1.25|0.75|1|...这个循环增益完全是bbr自主的循环增益，不受任何外界控制，是否进入下一个增益取决于以下的判断：
1.正增益周期，是否在不丢包情况下已经填满了可用带宽，这个旨在提高资源利用率(效率因素)；
2.减损周期内，是否已经腾出了部分可以资源，这个旨在满足公平性(公平因素)；
3.平稳反馈周期是否足够久，使得共享资源的TCP连接有时间收敛到一个公平的位置(公平因素)。
这是个典型的效率优先兼顾公平的实例，但是我们可以看到，如果上述的第三点，即平稳反馈周期太久会怎样？很显然，这样的话会降低bbr的抢占性和灵活性，bbr发现带宽富余的最短时间就是6个RTT，这对于某些场景而言显然是不足的。因此，我们可以得出第一个结论：
PROBE_BW状态中平稳反馈周期的长度决定