个人感悟—来自Google的TCP BBR拥塞控制算法解析

地址：TCR BBR拥塞控制算法另类解析

写本文的初衷一部分来自于工作，更多的来自于发现国内几乎还没有中文版的关于TCP bbr算法的文章，我想抢个沙发。本文写于2016/10/15！

        本文的写作方式可能稍有不同，之前很多关于OpenVPN，Netfilter，IP路由，TCP的文章中，我都是先罗列了问题，然后阐述如何解决这个问题。但是本文不同！本文的内容来自于我十分厌恶的一个领域，其中又牵扯到我十分厌恶的一家公司-华夏创新(Appex)，这些令我厌恶的东西让我不得不放弃很多的东西。所以，我不会先说业界遇到了什么问题，而是直接步入主题，阐述bbr算法的组成。我十分讨厌与人谈论关于TCP拥塞控制的话题，一方面是因为这个话题太过发散，任何人都可以说出自己的理由让人信服自己的忽悠人的算法，另一方面，我觉得我接触到的所有人当中并没有人真的懂这些(当然，我也不懂！而且比那些人更加不懂！)，所以我宁可花些时间在预研或者研发上，我也不想跟人瞎逼逼或者听别人瞎逼逼。
        随便提出一个TCP拥塞算法，任何人都可以做到说它好，任何人也可以做到说它不好，因为没人真的懂网络，所以聊这些是没有意义的！TCP不是网络范畴的技术，它是控制论范畴的，TCP技术不属于网络技术！
        我的观点是，正确的做法只有一种，其它的都是错误的做法，都没有意义！

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

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

使用BBR之前

我希望更多的人试用这个算法，并且与我共享测试结果，包括但不限于算法的带宽利用率，抢占性等！特别是温州皮鞋产老板！这个算法并不是我写的，既然开源那就不应该封闭于任何公司或者个人，所以我有权在这里就我知道的东西述说一二。

        我深深地明白，我以下写的这些有很多理解不周到的地方，我也深深的明白很多传统学生出身的人不会告诉我那些疏漏，我指的是温州老板那样的人，因为他们几乎都是在索取而不分享，如果他们发现了我的疏漏，他们会默默记上一笔，到头来他们学会了我分享的东西，他们又改进了我的疏漏(但是并不告诉我！)，他们又拥有自己独立学会的那些东西(他们也不会告诉我！)，所以，最终，他们任何人都比我更加博学且高明！然而不幸的是，这就是我的目标，我并不在乎那些人，我甚至不会在乎自己！

        所以，赶紧试用bbr吧，赶紧改进吧，功劳是你的，虚无是我的！

BBR的组成

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

1.即时速率的计算

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

2.RTT的跟踪

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

3.bbr pipe状态机的维持

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一窗数据全部突发出去，而这往往会造成路由器的排队，在深队列的情况下，会测量出rtt剧烈地抖动。
        bbr在计算cwnd的同时，还计算了一个与之适配的pacing rate，该pacing rate规定cwnd指示的一窗数据的数据包之间，以多大的时间间隔发送出去。

5.其它外部机制的利用-fq，rack等

bbr之所以可以高效地运行且如此简单，是因为很多机制并不是它本身实现的，而是利用了外部的已有机制，比如下一节中将要阐述的它为什么在计算带宽bw时能如此放心地将重传数据也计算在内...

带宽计算细节以及状态机

1.即时带宽的计算

bbr作为一个纯粹的拥塞控制算法，完全忽略了系统层面的TCP状态，计算带宽时它仅仅需要两个值就够了：
1).应答了多少数据，记为delivered；
2).应答1)中的delivered这么多数据所用的时间，记为interval_us。
将上述二者相除，就能得到带宽：
bw = delivered/interval_us
非常简单！以上的计算完全是标量计算，只关注数据的大小，不关注数据的含义，比如delivered的采集中，bbr根本不管某一个应答是重传后的ACK确认的，正常ACK确认的，还是说SACK确认的。bbr只关心被应答了多少！
        这和TCP/IP网络模型是一致的，因为在中间链路上，路由器交换机们也不会去管这些数据包是重传的还是乱序的，然而拥塞也是在这些地方发生的，既然拥塞点都不关心数据的意义，TCP为什么要关注呢？反过来，我们看一下拥塞发生的原因，即数据量超过了路由器的带宽限制，利用这一点，只需要精心地控制发送的数据量就好了，完全不用管什么乱序，重传之类的。当然我的意思是说，拥塞控制算法中不用管这些，但这并不意味着它们是被放弃的，其它的机制会关注的，比如SACK机制，RACK机制，RTO机制等。