24-TCP 协议（拥塞控制）

1.概述

在学习拥塞控制前，我们假设：接收方总是有足够大的缓存空间，接收方的接收窗口大小总是很大——这意味着接收方对数据来者不拒。

在基于这样的理想条件上，如果发送方发送的数据接收方没有收到，那么大抵上可以判断为网络出现了拥塞。

2. 网络拥塞是怎么来的

图1 某个小型局域网

图 1 所示的是一个典型的小型局域网，SW 表示交换机，R 表示路由器。基于第 1 节中所述的假设，如果 PC1 给主机 PC3 发送 TCP 报文的时候，出现了丢失，我们大抵上就可以猜测：PC1—SW1—R1—R2—PC3 这条网络路径，出现了拥塞。

为什么会出现这种情况呢？可能有以下原因：PC1 发送数据的速度太快了，导致了 SW1、R1、R2 忙不过来。

实际上，无论是交换机也好，路由器也好，他们转发数据都是按照“存储+转发”的方式进行的——即接收到数据后先保存到自己的缓存，然后再挨个处理，发送到对应的接口。

所谓的 SW1、R1、R2 忙不过来，就是指这些设备的缓存有限，你发送太快，我没地方进行缓存，导致的结果就是将数据丢弃。

3. 如何避免拥塞

从图 1 中可以看到，路径上的任意一个节点都有可能“忙不过来”，那么发送方如何才能知道按照什么样的速度发送数据呢？

唯一的方法就是尝试各种不同的发送速度。比如一开始以 100kb/s 的速率发送数据，如果没问题，再将速率提高到 200kb/s，再没问题继续提升发送速率。一旦达到某个上限后，便开始出现丢包现象，发送方就可以认为，网络已经拥塞了，于是降低发送速率，减轻网络负担。

我们将上面这种探测网络拥塞的方法称为拥塞控制。当然了，上面这种方法实在是太简单了。

早在 1999 年，RFC 2581 就定义了四种拥塞控制算法：

• 慢启动（slow-start）
• 拥塞避免（congestiono avoidance）
• 快重传（fast retransmit）
• 快恢复（fast recovery）

有关这些算法，会在后面详细讨论。

4. 总结

• 理解第 1 节中，为什么要提出这样的假设条件
• 知道为什么网络会拥塞
• RFC 定义了 4 种拥塞控制算法