TCP 的拥塞控制主要是这几个关键字：
- 慢启动和拥塞避免(拥塞窗口从 1开始指数增加，达到阈值后线性增加)
- 快速重传和快速恢复（当收到三个重复的 ACK 之后，表明丢包，此时立即重传该包，而不等到定时器超时，同时取消慢启动，不再指数增加，而是一直线性增加）
BBR 的改进
终于转变了对“拥塞“这个概念的理解，经典的拥塞控制算法比如 reno 是将丢包作为拥塞的信号，然后降低发送速率。而在该算法中，不考虑丢包，而是基于这样一个定义：
当网络上的包数大于BDP(带宽时延乘积)时，就认为出现了拥塞。所以重点就在于如何准确地测量出瓶颈链路的带宽和整个链路的传播时延。
在1980年设计拥塞控制算法的时候，将拥塞等同于丢包没有很大问题的，当时路由器的缓存小，链路带宽也不高。但是现在，路由器的缓存已经很大了，基于丢包的拥塞算法会一直增加窗口，直至把瓶颈路径上的路由缓存填满，然后出现丢包。但是，在这个过程中时延已经增大到我们无法容忍的程度了，所以需要反思这种基于丢包的拥塞控制思想。
这个算法的实现也有一个重大的思路转变，那就是不能仅仅只控制发多少包，也就是用拥塞窗口cwnd和慢启动门限值ssthresh来控制发包的多少，我们还应该控制发包的速率，所以pacing_rate成为主要控制因素。
另外，这篇论文的出现也印证了我们的一个思路是可行的：丢包恢复和窗口管理解耦。如果我们发现有丢包，重传就好了嘛，至于发送速率如何调整，全部交给拥塞控制算法就好了。
