Linux 拥塞控制算法
我自己对BBR的总结就是：终于转变了对“拥塞“这个概念的理解，经典的拥塞控制算法比如reno/newReno/Cubic无一例外都是将丢包作为拥塞的信号，然后降低发送速率。而在该算法中，不考虑丢包，而是基于这样一个定义：当网络上的包数大于BDP(带宽时延乘积)时，就认为出现了拥塞。所以重点就在于如何准确地测量出瓶颈链路的带宽和整个链路的传播时延。
在1980年设计拥塞控制算法的时候，将拥塞等同于丢包没有很大问题的，当时路由器的缓存小，链路带宽也不高。但是现在，路由器的缓存已经很大了，基于丢包的拥塞算法会一直增加窗口，直至把瓶颈路径上的路由缓存填满，然后出现丢包。但是，在这个过程中时延已经增大到我们无法容忍的程度了，所以需要反思这种基于丢包的拥塞控制思想。 因为网络对TCP连接的两端来说是一个黑盒，没有明显的信息告诉我们说网络出现了拥塞(支持ECN的路由设备在现网中的普及率不高 )，所以我们只能通过反馈来推测的，这也就是为啥需要拥塞控制算法的原因之一了。 这个算法的实现也有一个重大的思路转变，那就是不能仅仅只控制发多少包，也就是用拥塞窗口cwnd和慢启动门限值ssthresh来控制发包的多少，我们还应该控制发包的速率，所以pacing_rate成为主要控制因素。 另外，这篇论文的出现也印证了我们的一个思路是可行的：丢包恢复和窗口管理解耦。如果我们发现有丢包，重传就好了嘛，至于发送速率如何调整，全部交给拥塞控制算法就好了。