1988 年 10 月，互联网差点死掉。
那一年，从 LBL（劳伦斯伯克利国家实验室）到 UC Berkeley 的链路，正常吞吐量应该是 32Kbps，实际跑出来只有 40bps。不是打错了小数点——是真的只有正常值的千分之一。数据包发出去，绝大多数在中间路由器的缓冲区里排队、溢出、被丢弃，然后发送端超时重传，制造更多数据包，堵得更厉害。这个正反馈循环有个学名：拥塞崩溃（congestion collapse）。
Van Jacobson 在那一年写了那篇改变互联网命运的论文，提出了慢启动和拥塞避免两个算法。从那以后，TCP 的每一个连接都不再是"想发多快就发多快"，而是被一套精密的拥塞控制机制管着——你能拿到多少带宽，取决于你和同一条链路上的其他连接怎么博弈。
这篇文章从 1988 年的 Reno 讲起，经过 NewReno 的修补、CUBIC 的重新设计，一直到 Google 在 2016 年推出的 BBR。四代算法，核心问题始终只有一个：多个连接如何公平且高效地共享一条链路的带宽？
每一代给出了不同的答案。每一个答案都带来了新的问题。
在开始之前：先搞清楚拥塞控制在控制什么
很多讲拥塞控制的文章上来就甩公式，但如果不先搞清楚一个前提问题，后面所有的算法细节都是悬浮的：TCP 的发送速率到底由什么决定？
答案是两个窗口取最小值：
发送窗口 = min(rwnd, cwnd)rwnd是接收窗口，由对端通告，告诉你"我的接收缓冲区还剩多少空间"。
