我们知道，BBR将Pacing Rate作为第一控制要素，按照计算得到的Pacing Rate平缓地发送数据包即可，既然是这样，拥塞窗口的存在还有何意义呢？

　　BBR的拥塞窗口控制已经退化到了规定一个限额，它主要是为了灌满管道，解决由于ACK丢失导致的无包可发的问题。

　　我先来阐述问题。

　　BBR第一次把速率控制计算和实际的传输相分离，又一个典型的控制面与数据面相分离的案例。也就是说，BBR核心模块计算出一个速率，然后就把数据包扔给Pacing发送引擎模块(当前的实现是FQ，我自己也实现了一个)，具体何时发送由Pacing发送引擎来控制，atv直播，二者之间通过一个发送缓冲区来交互，具体结构如下图：

　　可见，拥塞窗口控制的是“到底扔多少数据到发送缓冲区合适”的。接下来的问题显然就是，拥塞窗口到底是多少合适呢？

　　虽然BBR分离了控制逻辑和数据发送逻辑，但是TCP的一切都是ACK时钟驱动的，如果ACK该来的时候没有来，比如说丢了，比如延迟了，那么就会影响BBR整个核心的运作，进而影响Pacing发送引擎的数据发送动作，BBR要做的是，即便没有ACK来驱动，也可以自行发送本该发送的数据包，因此Pacing发送引擎的发送缓冲区的意义重要，说白了就是，发送缓冲区里一定要有足够的数据包才行，就算ACK没有来，引擎还是有包可发的。

　　下面来展示一幅图：

　　如果这个图有不解之处，像往常一样，大家一起讨论，但总的来讲，我觉得问题不大，所以说才会基于上图产生了下图：

　　该图示中，我把TCP层的BBR核心模块和FQ的发送模块都画了出来，这样我们可以清晰看出拥塞窗口的作用。实际上，BBR核心模块按照拥塞窗口即inflight的限制，将N个数据包注入到Pacing发送引擎的发送缓冲区中，这些包会在这个缓冲区内部排队，最终在轮到自己的时候被发送出去。由于这个缓冲区里有足够的数据包，所以即使是ACK丢失了多个，或者接收端有LRO导致ACK被大面积聚集且延迟，发送缓冲区里面的数据包也足够发送一阵子了。

　　维护这么一个发送缓冲区的好处是在缓冲区不溢出(为什么不溢出？那是算出来的，正好两倍)的前提下时时刻刻有包可发，然而代价也是有的，就是增加了RTT，因为在发送缓冲区里排队的时间也要被算在RTT里面的。不过这无所谓，这并不影响性能，数据包不管是在TCP层的发送队列里，还是在FQ的队列里，最终都是要发出去的。值得注意的是，本地的FQ队列和中间节点的队列性质完全不同，本地的队列是独占的，主动的，而中间节点队列是共享的，被动的，所以这里并没有因为RTT的增加而损失性能。这就好比你有一张银行卡专门用来还房贷，由于利息的浮动，所有每月还款金额不同，为了不欠款，你每个月总是要存进足额的钱进去，一般要远多于平均的还贷额度才最保险，但这并不意味着你多存了钱这些钱就亏了，在还清贷款之前，存进去的钱早晚都是要还贷的。

　　3. 为什么在探测最小RTT的时候最少要保持4个数据包

　　首先要注意的是，用1个包去探测最小RTT会更好，然而效率可能会更低；用5个包去探测最小RTT效率更好，但是可能会导致排队，为什么4个包不多也不少呢？

　　我尝试用一个时序图来说明问题：

　　可见，4个包的窗口是合理的，infilght分别是：刚发出的包，已经到达接收端等待延迟应答的包，马上到达的应答了2个包的ACK。一共4个，只有1个在链路上，另外1个在对端主机里，另外2个在ACK里。路上只有1个包，这绝对合理，如果一条路连1个包都容纳不下了，那还玩个屎啊！

　　以上的论述，仅仅为了帮大家理解以下一段注释的深意：

　　4. 用时序图总览一下BBR的Startup/Drain/ProbeBW阶段

　　我以下面的时序图展示一下BBR的流程：

　　5. Startup阶段拥塞窗口计算的滞后性