案例库 · 软件与 IT · 技术决策 · 1986–1990
TCP慢启动通过温和探测解决了互联网拥塞崩溃
Van Jacobson 1988年的修复方案让发送方速率翻倍直到丢包,然后减半——这样互联网就根据路径能够承载的量自适应调整。
劳伦斯伯克利国家实验室
那一手
1986年10月,随着负载增长,互联网的吞吐量下降到容量的千分之一左右,尽管没有一条链路损坏。Van Jacobson诊断出了原因:发送方以最快速度发送数据,并在丢包时以全速重传,导致网络将容量投入到重传会被再次丢弃的数据包上。
他于1988年发表的论文提出了慢启动和拥塞避免。发送方起初只发送一个数据段,每收到一个确认就将窗口加倍,直到检测到丢包,然后将窗口减半并缓慢增加。每个发送方不是假定路径容量,而是通过反馈来测量和适应。
该设计在开始时特意保守,因为了解可用带宽的唯一方法就是探测,而安全的探测只能温和进行。由此产生的行为——加法增加、乘法减少——使成千上万的连接能够共享同一条路径而无需中央调度器。
为什么管用
- 丢失被视为信号而非错误,因此发送方能够在网络泛滥之前做出反应。
- 指数增长能快速找到容量,同时丢包时减半保证了恢复的安全。
- 该算法是局部的:每个发送方根据自身的反馈进行调整,因此系统能够扩展到数百万个连接。
- 它通过改变一个协议的行为而不是更换硬件就修复了系统性故障。
值了多少温和地探测容量;丢包时减半神来之笔
可以搬走什么
当系统容量未知且需要共享时,让每个参与者保守地探测并在反馈时退避——这样整体就会自我调节。
后来呢
慢启动和拥塞避免成为TCP拥塞控制的核心,并在1997年被编入RFC 2001。后来的变体(如NewReno、CUBIC、BBR)细化了探测规则,但探测与退避的原理至今仍主导着互联网的带宽共享方式。
资料来源
- Congestion Avoidance and Control
- RFC 2001 — TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms
发现哪里写错了?告诉我们。