TCP cubic算法和bbr算法

1. 前言

前段时间调试网络相关的功能时发现，在一定的丢包率情况下，使用tcp bbr算法比cubic算法有更好的网络传输表现（拉流更顺畅）。

本文仅仅记录一次网络调试经验以及网上查找的一些结论性的内容。对于两种tcp拥塞控制算法的具体实现不做深究，更多的是了解两种算法的表现情况及使用场景。

2. cubic和bbr算法对比

查询相关资料，两种tcp拥塞算法的表现情况如下：

Reno/CUBIC：
它们是事件驱动的！无论是丢包，还是RTT增加，都被视为一种严重的事件，这些严重的事件导致TCP拥塞控制系统在”To find current bandwidth“，”To avoid congestion“以及
”To probe more bandwidth“之间切换，最终落实下来的就是促使拥塞算法(无论Reno，Vegas还是CUBIC)调整窗口的大小。
那么谁来发现这些事件是否发生呢？答案是TCP拥塞控制状态机。拥塞控制状态机直接主导这些状态的切换，只要它发现丢包，不管是不是真的，都会拉低窗口值。
所以说，Reno/CUBIC的窗口调整是被动的。

BBR：
bbr是反馈驱动的！bbr内置了自主的调速机制，不受TCP拥塞控制状态机的控制，bbr算法是自闭的，它可以自己完成VJ的所有状态探测以及切换，无需外界干涉，且对外界的干涉视而不见。
bbr周期性的试图探测是否有更多的带宽，如果有，那么就利用它，如果没有，就退回到之前的状态。
所以说，bbr的窗口调整是主动的。

3. cubic和bbr使用场景

网络在没有丢包的情况下，cubic和BBR对于这些较长时延的链路都有很好的表现。而在中度丢包的情况下，BBR的表现就非常突出了。

1. 若仅仅在内网使用，内网环境带宽高，时延低，低丢包率的情况下，建议继续使用 cubic；
2. 若对外提供服务，建议使用 BBR，并使相应的网卡使用 tc-fq 调度，否则可能占用额外的 CPU 资源，影响性能；
3. BBR的公平性存在问题，它会抢占Cubic算法的带宽（取决于瓶颈缓冲区的大小）
4. BBR的机制会导致高重传率

BBR和Cubic两者擅长处理的网络环境并不相同。不过它不采用丢包作为拥塞信号，而是通过自己评估，也许会在其他的环境下取得更好的成绩，比如说和强化学习相结合。

4. 参考文献

• https://aws.amazon.com/cn/blogs/china/talking-about-network-optimization-from-the-flow-control-algorithm/
• https://www.cnblogs.com/jkc626/p/13702033.html
• https://blog.csdn.net/dog250/article/details/52962727