最近，我写了一篇题为”网络六十年“的文章，主要讨论互联网和阿帕网，我收到了很多评论都在讨论各种占据主导地位的网络技术。其中包括 OSI 栈（还有人记得 CLNP 和TP4 吗？）、Colored Book 协议（包括Cambridge Ring），当然还有 ATM（异步传输模式）。

虽然放到现在大家都很难理解，但在 20 世纪 80 年代，许多人认为 ATM 会成为统治世界的分组交换技术，而我也是其中之一。ATM 的支持者习惯将以太网和 TCP/IP 等现有技术称为“遗留”协议，他们认为一旦全球 ATM 网络建立，这些协议就可以在 ATM 网络上运行。我对那些日子的美好回忆之一便是 Steve Deering（IP 网络先驱）大胆（且正确）地指出 ATM 永远不可能获得巨大成功，甚至没有资格成为一种遗留协议。

我省略了其他协议，原因之一只是为了节省篇幅，因为我非常注重文笔简洁，尤其是我和 Larry L. Peterson 合著的书籍在亚马逊上收到了一条一星差评（https://www.amazon.com/gp/customer-reviews/R1IVEX207N7WY8/ref=cm_cr_srp_d_rvw_ttl?ie=UTF8&ASIN=B004VF6216），称我们的书为“文字墙”（比喻很多文字密密麻麻像堵墙一样，没有分段或标点符号）。但我重点讨论了互联网发展至今的经过，以及 TCP/IP 如何战胜其他协议套件渗透到全球（接近全球）。

关于 TCP/IP 为何比同时代的其他协议更成功的理论有很多，但这些理论都无法得到检验。我认为最主要的原因是，许多因素影响了互联网协议的成功，但我认为拥塞控制是推动互联网从中等规模发展至全球的关键因素之一。探讨 20 世纪 70 年代我们选择的某个架构如何在之后的几十年中证明自己，这也是一项有趣的研究。

分布式资源管理

David Clark 在论文《The Design Philosophy of the DARPA Internet Protocols》（DARPA 互联网协议的设计理念）中阐述了一条设计目标：“互联网架构必须允许对其资源进行分布式管理”。该目标有许多不同的含义，但 Jacobson 和 Karels 首次在 TCP 中实现拥塞控制的方式正是这一原则的一个很好的例子。

他们的方法还包含了互联网的另一个设计目标：适应许多不同类型的网络。总而言之，这些原则几乎排除了任何类型的基于网络的准入控制的可能性，与 ATM 等网络形成鲜明对比，后者假设针对资源的请求必须由终端系统发起之后数据才能流动。“适应许多不同类型的网络”的理念意味着，你不能假设所有网络都有准入控制。再结合资源的分布式管理，最终导致拥塞控制成为了终端系统不得不处理的工作，而这正是 Jacobson 和 Karels 最初对 TCP 的修改。

TCP 拥塞控制的历史很长，足以写满一本书（而且我们真的写了一本这样的书，https://tcpcc.systemsapproach.org/），但 1996 年~1998 年伯克利所做的工作留下了很长的阴影，而 Jacobson 于 1988 年发表的 SIGCOMM 论文也成为了有史以来被引用次数最多的网络论文之一。

慢启动、和性增长/乘性降低（Additive-Increase/Multiplicative-Decrease，AIMD）、RTT 估计以及将丢包作为拥塞信号等技术都出自该论文，为接下来几十年的拥塞控制研究奠定了基础。我认为，该论文具有如此影响力的一个原因是它奠定了坚实的基础，同时为将来的改进留足了空间。这个问题本质上非常难：我们在设法让数百万个彼此没有直接联系的终端系统以某种适度公平的方式合作共享瓶颈链路的带宽，而能够利用的信息仅仅是发送数据包进入网络并观察这些数据包何时以及是否到达目的地。

我认为，1988 年之后最大的飞跃之一是 Brakmo 和 Peterson 认识到了数据包丢失并不是拥塞的唯一信号，延迟增加也是此类信号之一。于 1994 年发表的 TCP Vegas 的论文正是以此为基础，使用延迟（而不仅仅是使用数据包丢失）的想法在当时颇有争议。然而，Vegas 开启了拥塞控制研究的新趋势，启发了许多其他人，他们将延迟作为在数据包真正丢失之前发现拥塞的指标。Data center TCP（DCTCP）以及 Google 的 BBR 就是两个例子。

我认为，拥塞控制算法对于互联网成功的贡献之一是，互联网的失败之路早在 1986 年就已经清晰地展现出来了。Jacobson 描述了一些早期的拥塞崩溃事件，在这些事件中人们发现网络吞吐量下降了三个数量级。1995 年我加入思科时，仍然能够听到有关客户遇到灾难性拥塞事件的故事。同年，以太网发明者以及图灵奖获得者 Bob Metcalfe 预言道：随着消费者访问互联网和 Web 的兴起推动流量快速增长，互联网终将崩溃。

然而，事实并非如此。拥塞控制不断发展，例如 QUIC 协议，提供了更好的拥塞检测机制和试验多种拥塞控制算法的备选方法。一些拥塞控制已转移到应用层，例如基于 HTTP 的动态自适应流（Dynamic Adaptive Streaming over HTTP，DASH）。

20 世纪 80 年代和 90 年代的拥堵事件的一个有趣的副作用是，我们观察到小的缓冲区有时会成为引发拥堵崩溃的原因。Villamizar 和 Song 发表的一篇颇具影响力的论文表明，当缓冲量 < 平均延迟 × 带宽时，TCP 的性能就会下降。不幸的是，这个结果仅适用于极少数的流量（论文中也提到了这一点），但这成为了接下来几年路由器设计的不可违反的规则。Appenzeller 等人在2004年对缓冲区大小的研究最终证明了这一理论的错误，但很可惜在这之前，上百万的低端路由器就因为过度增加缓冲区大小而导致了缓冲膨胀（Bufferbloat）现象——因数据包缓冲过大而引起网络高延迟的现象。你可以检查一下家里的网络是否存在“缓冲膨胀”的问题（https://www.waveform.com/tools/bufferbloat）。

我们无法回到过去，通过实验来确切地了解互联网如何走向了成功，而其他协议套件都在中途放弃了，但至少我们可以看到互联网由于及时添加了拥塞控制而避免了潜在的失败。在 1986 年，试验新想法相对容易，我们可以调整几个终端系统中的代码，然后将有效的解决方案推广到广泛的系统中。网络内部不需要任何改变。几乎可以肯定的是，当时需要修改的操作系统以及能够进行这些修改的人员社区非常小，所以 Jacobson 和 Karels 最初的基于 BSD 的算法能够得到广泛部署。

很明显，完美的拥塞控制方法并不存在，这就是为什么在 Jacobson 发表论文 35 年后，我们仍然能不断看到有关该主题的新论文。但互联网的架构营造了一个环境，我们可以在其中测试和部署有效的解决方案，以实现共享资源的分布式管理。在我看来，这很好地证明了该架构的质量。

欢迎参与 CSDN 重磅发起的《2023 AI 开发者生态调查问卷》，分享您真实的 AI 使用体验，更有精美好礼等你拿！