TCP协议的拥塞控制机制

最初的TCP协议只有基于窗口的流控制（flow control）机制而没有拥塞控制机制。流控制作为接受方管理发送方发送

数据的方式，用来防止接受方可用的数据缓存空间的溢出。流控制是一种局部控制机制，其参与者仅仅是发送方和接

收方，它只考虑了接收端的接收能力，而没有考虑到网络的传输能力；而拥塞控制则注重于整体，其考虑的是整个网

络的传输能力，是一种全局控制机制。正因为流控制的这种局限性，从而导致了拥塞崩溃现象的发生。 

1986年初，Jacobson开发了现在在TCP应用中的拥塞控制机制。运行在端节点主机中的这些机制使得TCP连接在网

络发生拥塞时回退（back off），也就是说TCP源端会对网络发出的拥塞指示（congestion notification）（例如丢

包、重复的ACK等）作出响应。1988年Jacobson针对TCP在控制网络拥塞方面的不足，提出了“慢启

动”（SlowStart）和“拥塞避免”（Congestion Avoidance）算法。1990年出现的TCP Reno版本增加了“快速重传 

”（Fast Retransmit），“快速恢复”（Fast Recovery）算法，避免了网络拥塞不严重时采用“慢启动”算法而造成过大地

减小发送窗口尺寸的现象，这样TCP的拥塞控制就由这4个核心部分组成。近几年又出现TCP的改进版本如NewReno

和选择性应答（selective acknowledgement，SACK）等。正是这些拥塞控制机制防止了今天网络的拥塞崩溃。 

慢启动阶段：早期开发的TCP应用在启动一个连接时会向网络中发送大量的数据包，这样很容易导致路由器缓存空间

耗尽，网络发生拥塞，使得TCP连接的吞吐量急剧下降。由于TCP源端无法知道网络资源当前的利用状况，因此新建

立的TCP连接不能一开始就发送大量数据，而只能逐步增加每次发送的数据量，以避免上述现象的发生。具体地说，

当建立新的TCP连接时，拥塞窗口（congestion window，cwnd）初始化为一个数据包大小。源端按cwnd大小发送数

据，每收到一个ACK确认，cwnd就增加一个数据包发送量，这样cwnd就将随着回路响应时间（Round Trip Time，

RTT）呈指数增长，源端向网络发送的数据量将急剧增加。事实上，慢启动一点也不慢，要达到每RTT发送W个数据

包所需时间仅为RTT×logW。由于在发生拥塞时，拥塞窗口会减半或降到1，因此慢启动确保了源端的发送速率最多

是链路带宽的两倍。 

拥塞避免阶段：如果TCP源端发现超时或收到3个相同ACK副本时，即认为网络发生了拥塞（主要因为由传输引起的

数据包损坏和丢失的概率很小（<<1%））。此时就进入拥塞避免阶段。慢启动阈值（ssthresh）被设置为当前拥塞

窗口大小的一半；如果超时，拥塞窗口被置1。如果cwnd>ssthresh，TCP就执行拥塞避免算法，此时，cwnd在每次

收到一个ACK时只增加1/cwnd个数据包，这样，在一个RTT内，cwnd将增加1，所以在拥塞避免阶段，cwnd不是呈

指数增长，而是线性增长。 

快速重传和快速恢复阶段：快速重传是当TCP源端收到到三个相同的ACK副本时，即认为有数据包丢失，则源端重传

丢失的数据包，而不必等待RTO超时。同时将ssthresh设置为当前cwnd值的一半，并且将cwnd减为原先的一半。快

速恢复是基于“管道”模型（pipe model）的“数据包守恒”的原则（conservation of packets principle），即同一时刻在

网络中传输的数据包数量是恒定的，只有当“旧”数据包离开网络后，才能发送“新”数据包进入网络。如果发送方收到

一个重复的ACK，则认为已经有一个数据包离开了网络，于是将拥塞窗口加1。如果“数据包守恒”原则能够得到严格遵

守，那么网络中将很少会发生拥塞；本质上，拥塞控制的目的就是找到违反该原则的地方并进行修正。