我们知道，BBR里面拥塞窗口已经不再是主控因素，事实上它的名字应该改成“发送缓冲区限额”会比较合适了，为了方便起见，我仍然称它为拥塞窗口，虽然它的含义已经改变。

　　在Startup阶段，发送速率每收到一个ACK都会提高bbr_high_gain：

　　这个其实跟传统拥塞算法的“慢启动”效果是类似的。

　　然而BBR计算拥塞窗口是用“当前采集到的速率”乘以“当前采集到的最小RTT”来计算的，这就造成了“当前发送窗口”和“当前已经提高的速率”之间的不匹配，所以，计算拥塞窗口的时候，gain因子也必须是bbr_high_gain，从而可以吸收掉速率的实际提升。

　　6. 由ACK通告的接收窗口还有意义吗？

　　在以往的Reno/CUBIC年代，窗口的计算是根据既有的固定数学公式算出来的，完全仅仅由ACK来驱动，无视事实上的传输速率，所以彼一时的拥塞窗口仅仅可以代表网络的情况，即便如此，这种网络状态的结论也是猜的。

　　到了BBR时代，主动测量传输速率，将网络处理能力和主机处理能力合二为一，如果网络瓶颈带宽为10，而主机处理能力为8，那么显然采集到的带宽不会大于8！反之亦然。如果BBR测量的即时速率很准确的话，我想通告窗口就完全没有意义了，通告的接收窗口会被忠实地反映在发送端采集到的即时速率里。BBR只是重构了拥塞控制算法，但还没有重构TCP处理核心，我想BBR可以重构之！

　　7. BBR在计算拥塞窗口时其它的关键点

　　1) 延迟ACK的影响

　　计算拥塞窗口的时候，会将目标拥塞窗口进行一下调整：

　　此处向上取偶数就是为了平滑最后一个延迟ACK的影响，如果最后一个延迟ACK该来的没来，那么这个向上取偶数可以为之补上。

　　2) Offload的影响

　　8. 关于我的Pacing发送引擎

　　我在今年1月份写了一版和TCP BBR相结合的Pacing发送引擎，以消除FQ对RTT测量值(增加排队延迟)的影响，个人觉得我这个要比FQ那个好很多，毕竟是原汤化原食的做法吧。

　　直接在TCP层做Pacing其实并不那么Cheap，因为三十多年来，TCP并没有特别严重的Buffer bloat问题，所以TCP的核心框架实现几乎都是突发数据包的，完全靠ACK来驱动发送，这个TCP核心框架比较类似一个令牌桶，而不是一个整型器！

　　令牌桶：决定能不能发送；

　　整型器：决定如何发送数据，是突发还是Pacing发送；

　　可见这两者是完全不同的机制！要想把一个改成另一个，这个重构的工作量是可想而知。因此我实现的那个TCP Pacing只是一个简版。真正要做得好的话，势必要重构TCP发送队列的操作策略，比如出队，入队，调度策略。

　　现阶段，我们能使用的一个稳定版本的Pacing替代方案就是FQ，我们看看Linux的注释怎么说：