Google的BBR拥塞控制算法

背景

传统基于预测的TCP拥塞控制

• 以Reno的改进为例，TCP发送端在拥塞避免阶段收到ACK后，无条件地将cwnd增加1/cwnd，在慢启动阶段收到ACK后cwnd增加1，这是毫无根据的，然而Reno并没有什么更好的做法，只能瞎猜！
• 后来Cubic也改进了一波，搞了一个高大上的以三次方程凸凹曲线来抉择的增窗机制，看似十分地“博士”，并且十分地“经理”，然而还是无法高效利用互联网的空闲带宽，相反在碰到异常现象，比如丢包，拥塞的时候，反应太过保守，在保守的路线上趋于激烈，即激烈地保守降低拥塞窗口，更加可悲的是，这个窗口下降的过程并不受这些算法所控制。

拥堵算法，状态机一人管

• 拥塞算法内部是受外部的拥塞状态影响的，比如说在Recovery状态下，甚至都不会进入拥塞控制算法，在bbr进入内核之前，Linux使用PRR算法控制了Recovery状态的窗口调整，即便说这个时候网络已经恢复，TCP也无法发现，因为TCP的Recovery状态还未恢复到Open，这就是根源！
• 按照“上帝的事情上帝管，凯撒的事情凯撒管”的原则，这两件事本来就该由不同的机制来完成，不考虑对端接收窗口的情况下，拥塞窗口是唯一的主导因素，“传输多少数据”这件事应该由拥塞算法来回答，而“传输哪些数据”这个问题应该由TCP拥塞状态机以及SACK分布来决定，诚然这两个问题是不同的问题，不应该杂糅在一起。
• 在bbr进入内核之前的Linux TCP实现中