• 获取pdf：密码7281
• 专栏目录首页：【专栏必读】考研湖科大教书匠计算机网络笔记导航

本节对应视频如下

• 【计算机网络微课堂（有字幕无背景音乐版）】：TCP拥塞控制

一：拥塞控制概述

拥塞控制：在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏。这种情况就叫做拥塞。在计算机网络中的链路容量(即带宽)、交换结点中的缓存和处理机等，都是网络的资源。若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降，这便是拥塞控制的作用如下图，横坐标是输入负载，代表单位时间内输入给网络的负载数量，纵坐标是吞吐量，代表单位时间内从网络输出的分组量

具有理想拥塞控制的网络

• 在吞吐量达到饱和之前，网络吞吐量应该等于所输入的负载，故吞吐量是45度的斜线
• 当输入负载超过某一限度时，由于网络资源受限，吞吐量就不再增长而保持水平，也就是吞吐量达到饱和，这就表明输入的负载中有一部分损失掉了，例如输入到网络中的某些分组被某个结点丢弃了

对于实际情况中的网络

• 随着输入负载的增大，网络吞吐量的增长率逐渐减小，也就是在网络吞吐量还未达到饱和之前，就已经有一部分输入分组被丢弃了
• 当网络吞吐量明显小于理想吞吐量时，网络就进入了轻度拥塞状态
• 当输入负载达到某一数值时，网络吞吐量反而随输入负载的增大而减小，这时网络就进入了拥塞状态
• 当输入负载继续增大到某一数值时，网络的吞吐量就减小为0，此时网络便瘫痪了

因此进行拥塞控制是非常有必要的，实际的拥塞控制曲线应该尽量接近理想的拥塞控制曲线

二：拥塞控制四大算法

下面我们介绍四种拥塞控制算法的基本原理，假定如下条件

• 数据是单方向传送，而另一个方向只传送确认
• 接收方总是有足够大的缓存空间，因而发送方发送窗口的大小由网络的拥塞程度来决定
• 以最大报文段MSS的个数为讨论问题的单位，而不是以字节为单位

如下图，发送方向接收方发送TCP数据报文段，接收方收到后给发送方发送TCP确认报文段

（1）慢开始和拥塞避免

发送方维护一个叫做拥塞窗口cwnd的状态变量，其值取决于网络的拥塞程度，并且动态变化

• 拥塞窗口cwnd的维护原则：只要网络没有出现拥塞，拥塞窗口就再增大一些；只要网络出现拥塞，拥塞窗口就减少一些
• 判断出现网络拥塞的依据：没有按时收到应当到达的确认报文(即发生超时重传)

发送方将拥塞窗口作为发送窗口swnd，即swnd = cwnd。同时还需要维护一个慢开始门限ssthresh状态变量

• 当cwnd < ssthresh时：使用慢开始算法;
• 当cwnd > ssthresh时：停止使用慢开始算法而改用拥塞避免算法;
• 当cwnd = ssthresh时：既可使用慢开始算法，也可使用拥塞避免算法

为了更清晰地展示出拥塞控制过程，我们还可以绘制出一副拥塞窗口随传输轮次变化的图

• 横坐标为传输轮次：是指发送方给接收方发送数据报文段后，接收方给发送方发回相应的确认报文段，一个传输轮次所经历的时间其实就是往返时间（并非固定）。使用传输轮次是为了强调把拥塞窗口所允许发送的报文段都连续发送出去并收到了对已发送的最后一个报文段的确认
• 纵坐标是拥塞窗口：它会随网络拥塞程度以及所使用拥塞控制算法动态变化

在TCP双方建立连接逻辑关系时，拥塞窗口的值会设置为1，另外还需要设置ssthresh初始值为16

A：慢启动（slow start）

慢启动：发送方每收到一个对新报文段的确认时就把拥塞窗口值+1，然后开始下一轮传输，当拥塞窗口值增长到慢开始门限时就改为执行拥塞避免算法

如下图，发送刚当前拥塞窗口值为1，而发送窗口等于拥塞窗口，因此发送方当前只能发送一个TCP数据报文段

• 发送方发送0号数据报文段
• 接收方收到后，给发送方发回对0号报文段的确认报文段
• 发送方收到该确认报文段后，将拥塞窗口值+1变为2
• 这意味着发送方现在可以发送1-2号共两个数据报文段
• 接收方收到后，给发送方发回对1-2号报文段的确认报文段
• 发送方收到该确认报文段后，将拥塞窗口值+2变为4
• 这意味着发送方现在可以发送3-6号共三个数据报文段
• 接收方收到后，给发送方发回对3-6号报文段的确认报文段
• 发送方收到该确认报文段后，将拥塞窗口值+4变为8
• 这意味着发送方现在可以发送7-14号共八个数据报文段
• 接收方收到后，给发送方发回对7-14号报文段的确认报文段
• 发送方收到该确认报文段后，将拥塞窗口值+8变为16

发送方当前的拥塞窗口值已经增大到了慢开始门限值，之后需要启动拥塞避免算法

B：拥塞避免（congestion avoidance）

拥塞避免：和慢启动不同，拥塞避免在每个传输轮次结束后，拥塞窗口只能线性+1

如下图

• 发送方现在可以发送15-30号共16个数据报文段
• 接收方收到后，给发送方发回对15-30号报文段的确认报文段
• 发送方收到该确认报文段后，将拥塞窗口值+1变为17
• 发送方现在可以发送31-47号共17个数据报文段
• 接收方收到后，给发送方发回对31-47号报文段的确认报文段
• 发送方收到该确认报文段后，将拥塞窗口值+1变为18

重复上述过程很多次，发送方将171-194号共24个数据报文段发送后，其中有些报文段丢失了，这必然会造成发送方对这些丢失报文段的超时重传，发送方判断网络可能出现了堵塞，进行以下工作

• 将慢开始门限更新为发生拥塞时的一半，对于本例更新为12

• 将cwnd值减少为1，并重新开始执行慢开始算法
  

• 当慢开始执算法执行到拥塞窗口值增大到新的慢开始门限时，就停止使用慢开始算法，转而执行拥塞避免算法
  

C：总结

TCP发送方一开始使用慢开始算法，让拥塞窗口值从1开始按指数规律增大，当拥塞窗口值增大到慢开始门限值时，停止使用慢开始算法，转而执行拥塞避免算法，让拥塞窗口按线性+1的规律增大。当发生超时重传时，就判断网络很可能发生了拥塞，于是采取相应措施

• 将慢开始门限更新为发生拥塞时的一半
• 将cwnd值减少为1，并重新开始执行慢开始算法

拥塞窗口值又从1开始按指数规律增大，当增大到新的慢开始门限值时，停止使用慢开始算法，转而执行拥塞避免算法，让拥塞窗口按线性+1的规律增大

（2）快重传和快恢复

慢开始和拥塞避免算法是1988年提出的TCP拥塞控制算法(TCP Tahoe版本)。1990年又增加了两个新的拥塞控制算法(改进TCP的性能)，这就是快重传和快恢复(TCP Reno版本) 。这是因为个别报文段会在网络中丢失，但实际上网络并未发生拥塞

• 这将导致发送方超时重传，并误认为网络发生了拥塞;
• 发送方把拥塞窗口cwnd又设置为最小值1,并错误地启动慢开始算法，因而降低了传输效率

A：快重传（fast retransmit）

快重传：使发送方尽快进行重传，而不是等超时重传计时器超时再重传。采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失。具体来说

• 要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认
• 即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认
• 发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传

对于个别丢失的报文段，发送方不会出现超时重传，也就不会误认为出现了拥塞(进而降低拥塞窗口cwnd为1)。使用快重传可以使整个网络的吞吐量提高约20%

如下图

• 发送方发送1号数据报文段

• 接收方收到后给发送方发回对1号报文段的确认

• 在该确认报文段到达发送方之前，发送方还可以将发送窗口内的2号数据报文段发送出去

• 接收方收到后给发送方发回对2号报文段的确认

• 在该确认报文段到达发送方之前，发送方还可以将发送窗口内的3号数据报文段发送出去，但是该报文丢失了

• 接收方自然不会给发送方发回针对该报文段的确认
  

• 发送方还可以将发送窗口内的4号数据报文段发送出去

• 接收方收到后发现这不是按序到达的报文段，因此给发送方发回针对2号报文段的重复确认，表明现在希望收到的是3号报文段但是未收到，而是收到了未按序到达的报文段
  

• 发送方还可以将发送窗口内的5号数据报文段发送出去

• 接收方收到后发现这不是按序到达的报文段，因此给发送方发回针对2号报文段的重复确认
  

• 发送方还可以将发送窗口内的6号数据报文段发送出去

• 接收方收到后发现这不是按序到达的报文段，因此给发送方发回针对2号报文段的重复确认

• 至此，发送方会收到3个连续的对2号报文段的重复确认，就立即重传3号报文段
  

• 接收方收到后给发送方发回针对6号报文段的确认，表明序号到6为止的报文段都正确接收了，这样就不会造成对3号报文段的超时重传，而是提早进行了重传
  

B：快恢复（fast recovery）

快恢复：发送方一旦收到3个重复确认，就知道现在只是丢失了个别的报文段。于是不启动慢开始算法,而执行快恢复算法

• 发送方将慢开始J限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半; 开始执行拥塞避免算法
• 也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些，即等于新的ssthresh + 3
• 既然发送方收到3个重复的确认,就表明有3个数据报文段已经离开了网络;
• 这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中;
• 可见现在网络中不是堆积了报文段而是减少了3个报文段。因此可以适当把拥塞窗口扩大些

（3）总结