TCP，拥塞控制之BBR_算法介绍

很多朋友对TCP，拥塞控制之BBR_算法介绍不是很了解，每日小编刚好整理了这方面的知识，今天就来带大家一探究竟。

2016年10月的一个youtube链接：Making Linux TCP Fast，首次发布了BBR算法，TCP拥塞控制打开了新局面。

BBR很简单，背后是一个单流理想模型：

然而现实并不遵循这个模式，因此BBR的表现很难兑现其承诺。尤其是在多流场景下，公平性难以保证，并且频繁出现高重传吞吐量的情况。

下面是一个流程图：

这种性能的根本原因是“BBR 必须通过更多的飞行来探测潜在的带宽”。 “More inflight”与Loss-based算法的AI流程相同，但没有相应的MD反馈，这意味着BBR流量的inflight很容易被拉到高水位。飞行中高水位很容易导致排队甚至丢包，这与BBR的目标恰恰相反。

多码流共享瓶颈带宽，背景码流及其AIMD的入侵和退出容易对BBR造成干扰。 BBR记录瞬时检测增益并持续10轮。这种缓慢的响应使得BBR很难维持理想模型的状态机。

BBR 必须考虑更接近现实并限制飞行的场景。这就是BBRv2的背景。

以下背景引用来自：理解BBRv2

然而，在多个BBRv1 流中，每个发送方都会高估可用带宽，因为max_filter 会立即应用为新的发送速率；因此，从BBR 主机发送的数据总量超过了管道的容量，导致建立常设队列。如果缓冲区大小不足以存储多余的数据，则会发生数据包丢失。此外，这种数据包丢失在多个BBRv1 流的整个带宽共享中持续存在，因为无论发生多少数据包丢失，BBRv1 都不会减少传输数据的最大边界。上述飞行数据的最大边界就是飞行上限，计算为2 BDP，用于维持最大吞吐量和低延迟。

BBRv2的核心是“更准确地测量传输速率并根据丢包和ECN信号来约束飞行”。为此，BBRv2在ProbeBW状态中引入了子状态机：

以下是来自BBRv2 草案的约束详细信息：

下面是BBRv2流程示意图：

驱动BBRv2状态机转换的不再是固定阶段，而是完全基于“丢包”、“ECN-Mark”和“公平性”等变量“随时”向上探测或向下探测：

实时跟踪丢包率和ECN Mark，实时调整inflight_hi/lo，限制实际飞行。

实时跟踪丢包率和ECN Mark，辅以公平性保证，驱动子状态机的状态转换。

在巡航状态下，保留净空作为“公共奉献”。

BBRv2专门为Reno/CUBIC预留了AIMD周期的时间窗口。该窗口等于0.5*Max_cwnd=BDP RTT时间（具体计算请参考Jacobson pipeline）。两次探测的时间不小于该窗口。同时，也很明显没有理由。如果探测导致丢包，可以继续探测。

在上述窗口内，BBRv2 执行巡航而不向网络注入任何干扰，从而使Reno/CUBIC 能够安静AI。由于BBR 探测使用MI，因此它仅在时间窗口过去后执行一次MI。理论上，BBRv2和Reno/CUBIC具有相同的探测周期，建立了友好共存的基础。

正如BBRv2 草案第4.3.3.5.1 节中提到的，BBRv2 希望在DC 和Internet 上与Reno/CUBIC 友好共存。巧合的是，两类网络的典型BDP是相同的：

DC 网络：40 Gbps/8 位/字节* 20 us /（1514 字节）~=66 个数据包

互联网：25Mbps/8 位/字节* 30 ms /（1514 字节）~=62 个数据包

在超过60 个RTT 的探测后，BBRv2 可以以友好的方式再次探测。这个时间在互联网上大约是2秒，在DC网络上大约是1.3毫秒。时间刻度不包含固定的经验值。它是轮数的函数，并且适应各种类型的网络。这是BBR/Reno共存的事实上的保证。

与BBRv1的固定8轮相比，BBRv2的探测间隔要长得多。该策略是一个很好的策略，但是在我看来，在实际场景中，都是异步流程。 BDP RTT的AIMD周期属于高斯分布的右尾。取其预期平均值是高尚的，大约30 到40 RTT 是非常合理的。

最近读的一本书《系统之美》提到了“有限理性”这个词，也叫“看不见的脚”，与亚当斯密的“看不见的手”相对。 “有限理性”的概念完全适用于多流共享带宽的场景。 “有限理性”的后果就是“公地悲剧”。各方都自私地获利，但最终共同承担后果。这显然对各方都有利。 TCP AIMD可以完美应对“公地悲剧”，但BBRv1却不能。

在资源有限的系统中，BBRv2 越来越多地反馈外部后台事件，这就是进步，而BBRv1 似乎很少有全局观。结合“系统之美”，BBRv2在突破“公地悲剧”的道路上走上了正轨。

虽然单流吞吐量有所下降，但整体效果有所提升。

以TCP友好性为基础，并与Reno/CUBIC保持一致，BBRv2具备长期演进的可能性，最终将作为CUBIC的后继者成为默认的标准算法。相比之下，BBRv1仅提供了一种新的思路，但尚未准备好实际部署以及与传统TCP流的共存。

但直到Linux Kernel v6.1-rc2，BBRv2仍然没有被集成（相比之下，BBRv2在QUIC上进展得更快），并且仍然只存在于Google自己的分支中：https://github.com/google/bbr/blob/v2alpha/net /ipv4/tcp_bbr2.c

这项工作涉及DC 内TCP cc 的演变的讨论。对于短突发，我们倾向于将init cwnd 增加到大约1 BDP，并倾向于重用长连接。从idle启动的cwnd是init cwnd。对于长流，首选BBRv2。它确实比DCTCP适应性更强，并且包含了DCTCP的特性。记录一篇文章，可以作为资料参考，因为玄学的东西不是太多（不过还是有的）。

黄飞

以上知识分享希望能够帮助到大家！