Google的TCP BBR拥塞控制算法深度解析

原作者：dog250，授权发布

重新整理：极客重生

hi ，大家好，今天推荐一篇我认为在TCP BBR技术里面分析非常透彻的文章，希望大家可以学习到一些真正的知识，理解其背后的设计原理，才能应对各种面试和工作挑战！

宏观背景下的BBR

1980年代的拥塞崩溃导致了1980年代的拥塞控制机制的出炉，某种意义上这属于见招拆招的策略，针对1980年代的拥塞，提出了1980年代的拥塞控制算法，分为四个部分：慢启动、拥塞避免、快速重传、快速恢复：

说实话，这些机制完美适应了1980年代的网络特征，低带宽，浅缓存队列，美好持续到了2000年代。

随后互联网大爆发，多媒体应用特别是图片，音视频类的应用促使带宽必须猛增，而摩尔定律促使存储设施趋于廉价而路由器队列缓存猛增，这便是BBR诞生的背景。换句话说，1980年代的CC已经不适用了，2010年代需要另外的一次见招拆招。

如果说上一次1980年代的CC旨在收敛，那么这一次BBR则旨在 效能E最大化，这里的E就是本文上面大量篇幅描述的那个E，至少我个人是这么认为的，这也和BBR的初衷 提高带宽利用率 相一致！

插个形象的gif：

https://cloud.google.com/blog/products/networking/tcp-bbr-congestion-control-comes-to-gcp-your-internet-just-got-faster

正文开始

国庆节前，我看到了bbr算法，发现它就是那个唯一正确的做法(可能有点夸张，但起码它是一个通往正确道路的起点！)，所以花了点时间研究了一下它，包括其patch的注释，patch代码，并亲自移植了bbr patch到更低版本的内核，在这个过程中，我也产生了一些想法，作为备忘，整理了一篇文章，记如下，多年以后，再看TCP bbr算法的资料时，我的记录也算是中文社区少有的第一个吃螃蟹记录了，也算够了！

正文之前，给出本文的图例：

BBR的组成

bbr算法实际上非常简单，在实现上它由5部分组成：

BBR的组成

1.即时速率的计算

计算一个即时的带宽bw，该带宽是bbr一切计算的基准，bbr将会根据当前的即时带宽以及其所处的pipe状态来计算pacing rate以及cwnd，后面我们会看到，这个即时带宽计算方法的突破式改进是bbr之所以简单且高效的根源。计算方案按照标量计算，不再关注数据的含义。在bbr运行过程中，系统会跟踪当前为止最大的即时带宽。

2.RTT的跟踪

bbr之所以可以获取非常高的带宽利用率，是因为它可以非常安全且豪放地探测到带宽的最大值以及rtt的最小值，这样计算出来的BDP就是目前为止TCP管道的最大容量。bbr的目标就是达到这个最大的容量！这个目标最终驱动了cwnd的计算。在bbr运行过程中，系统会跟踪当前为止最小RTT。

3.BBR状态机的维持

bbr算法根据互联网的拥塞行为有针对性地定义了4中状态：

即STARTUP，DRAIN，PROBE_BW，PROBE_RTT。bbr通过对上述计算的即时带宽bw以及rtt的持续观察，在这4个状态之间自由切换，相比之前的所有拥塞控制算法，其革命性的改进在于bbr拥塞算法不再跟踪系统的TCP拥塞状态机，而旨在用统一的方式来应对pacing rate和cwnd的计算，不管当前TCP是处在Open状态还是处在Disorder状态，抑或已经在Recovery状态，换句话说，bbr算法感觉不到丢包，它能看到的就是bw和rtt！

4.结果输出-pacing rate和cwnd

首先必须要说一下，bbr的输出并不仅仅是一个cwnd，更重要的是pacing rate。在传统意义上，cwnd是TCP拥塞控制算法的唯一输出，但是它仅仅规定了当前的TCP最多可以发送多少数据，它并没有规定怎么把这么多数据发出去，在Linux的实现中，如果发出去这么多数据呢？简单而粗暴，突发！忽略接收端通告窗口的前提下，Linux会把cwnd一窗数据全部突发出去，而这往往会