5.5、TCP 的拥塞控制

在某段时间若$对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏$

• 这种情况就叫做$拥塞$(congestion)。

• 就是供不应求

• 在计算机网络中的$链路容量$（即带宽)、$交换结点中的缓存$和$处理机$等，都是网络的资源。

若$出现拥塞而不进行控制$，整个网络的$吞吐量将随输入负荷的增大而下降$。

---

1、理想/实际的拥塞控制

如下所示

• 输入负载：代表单位时间内输入给网络的分组数量
• 吞吐量：代表单位时间内从网络输出的分组数量

具有理想拥塞的网络，在吞吐量达到饱和之前，网络吞吐量应等于所输入的负载

• 即吞吐量曲线是 $45°$ 的斜线

但当输入负载超过某一限度时，由于网络资源受限，吞吐量就不再增长而保持水平线

• 也就是吞吐量到达饱和

这就表明输入的负载有一部分损失掉了

• 例如，输入到网络的某些分组被某个节点丢弃了

虽然如此，但这种理想的拥塞控制下，网络的吞吐量仍然维持在其所能到达的最大值

---

然而，实际的网络下，并不是这样的

如下所示

随着输入负载的增大，网络吞吐量逐渐减小

• 也就是再网络吞吐量还未达到饱和时，就已经有一部分的输入分组被丢弃了

当网络的吞吐量明显地小于理想的吞吐量时

• 网络就进入了轻度拥塞的状态

当输入负载达到某一数值时，网络的吞吐量随反而随着输入负载的增大而减小

• 这时，网络就进入了拥塞状态

当输入负载继续增大到某一数值时，网络的吞吐量就减小为 $0$

• 此时网络就无法工作量，这就是所谓的死锁

实际的拥塞控制曲线应该尽量接近理想的拥塞控制曲线

---

2、TCP的四种拥塞控制办法

慢开始（slow-start）、拥塞避免（congestion avoidance）、快重传（fast retransmit）、快恢复（fast recovery）

---

假定如下条件

• 数据是单方向传送，而另一个方向只传送确认。

• 接收方总是有足够大的缓存空间，因而发送方发送窗口的大小由网络的拥塞程度来决定。

• 以最大报文段 MSS 的个数为讨论问题的单位，而不是以字节为单位。

---

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

• 拥塞窗口 $\text{cwnd}的维护原则$：只要网络$没有出现拥塞$，$拥塞窗口$就再$增大$一些

  • 但只要网络$出现拥塞$，$拥塞窗口就减少$一些。

• 判断出现$网络拥塞的依据$：没有按时收到应当到达的确认报文（即$发生超时重传$)。

发送方将拥塞窗口作为$发送窗口\text{swnd}$，即$\text{swnd = cwnd}$。

维护一个慢开始门限 $\text{ssthresh}$ 状态变量:

当 $\text{cwnd < ssthresh}$ 时，使用慢开始算法;

当 $\text{cwnd > ssthresh}$ 时，停止使用慢开始算法而改用拥塞避免算法;

当 $\text{cwnd = ssthresh}$ 时，既可使用慢开始算法，也可使用拥塞避免算法。

2.1、慢开始(指数增长) & 拥塞避免(线性+1)

如下所示：拥塞窗口随传输轮次变化图

传输轮次：发送方给接收方发送数据报文段后，接收方给发送方发回相应的确认报文段

• 一个传输轮次所经历的时间其实就是往返时间

• 往返时间并非是恒定的数值

使用传输轮次是为了强调把拥塞窗口所允许发送的报文段连续发送出去，并收到了对已发送的最后一个报文段的确认

拥塞窗口：它会随网络拥塞程度以及所使用的拥塞控制算法动态变化

• 在 TCP 双方建立逻辑连接关系时，拥塞窗口的值设置为 $1$

慢开始门限的初始值此处设置为 $16$

2.1.1、TCP 报文段未丢失情况

在执行慢开始算法时，发送方每收到一个对新报文的确定时，就把拥塞窗口值 + 1，然后开始下一轮的传输

当拥塞窗口值增长到慢开始门限值时，就改为执行拥塞避免算法

由于当前拥塞窗口值是 $1$，而发送窗口值等于拥塞窗口值

• 因此，发送方当前只能发送一个 TCP 数据报文段
• 即：拥塞窗口值是几，就能发送几个 TCP 数据报文段

---

例如：此时发送方当前拥塞窗口值已经增大到了慢开始门限值

之后，改用拥塞避免算法

也就是每个传输轮次结束后，拥塞窗口值只能线性 + 1

• 而不像慢开始那样，每个传输轮次结束后，拥塞窗口值按指数规律增长

---

2.1.2、TCP 报文段丢失情况

例如：此时，发送方可以发送 $171$ ~ $194$ 共 $24$ 个数据报文段

假设这 $24$ 个数据报文段在传输过程中丢失了几个

• 则必然会造成发送方对这些丢失报文段的超时重传

发送方很可能判断网络出现了拥塞，需要进行以下工作

①将慢开始门限值更新为发生拥塞时拥塞窗口值的一半，如下所示

②将拥塞窗口值减少为 $1$，并重新开始执行慢开始算法，如下所示

---

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

• 转而执行拥塞避免算法

如下所示

---

2.1.3、小结

通过上述可以看出

1、一开始，TCP 发送方一开始使用慢开始算法，让拥塞窗口值从 $1$ 开始按指数规律增大

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

2、当超时重传是就判断网络可能出现了拥塞，采取相应的措施

• 一方面：将慢开始门限值更新为发生拥塞时拥塞窗口值的一半
• 另一方面：将拥塞窗口值减少为 $1$，并重新开始执行慢开始算法

3、拥塞窗口值又从 $1$ 开始按指数规律增大

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

---

2.1.4、注意

“慢开始” 是指一开始向网络注入的报文段少，并不是指拥塞窗口 $\text{cwnd}$ 增长速度慢;

“拥塞避免 ”并非指完全能够避免拥塞，而是指在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞;

---

2.2、快重传 & 快恢复

慢开始和拥塞避免算法是 $1988$ 年提出的TCP拥塞控制算法（TCP Tahoe版本）。

$1990$ 年又增加了两个新的拥塞控制算法（$改进\text{TCP}的性能$），这就是快重传和快恢复（TCP Reno版本)。

• 有时，$个别报文段$会在网络中$丢失$，但实际上网络$并未发生拥塞$。

• 这将导致$发送方$超时重传，并$误认为$网络发生了$拥塞$;

• $发送方把拥塞窗口\text{cwnd}又设置为最小值1$，并错误地启动慢开始算法，因而$降低了传输效率$。

例如：如下所示，当拥塞窗口值增大到 $24$ 时，发生了超时重传

• 而网络并没有发生拥塞，但是发送方却误认为网络发生了拥塞

---

2.2.1、快重传算法

采用快重传算法可以KaTeX parse error: Unexpected end of input in a macro argument, expected '}' at position 12: \color{\red}̲让发送方尽早知道发生了个别报文…。

所谓快重传，就是使发送方$尽快进行重传$，而$不是等超时重传计时器超时$再重传。

• 要求接收方不要等待自己发送数据时才进行捎带确认，而是要$立即发送确认$;

• 即使收到了失序的报文段也要立即发出对已收到的报文段的$重复确认$。

• 发送方一旦$收到3个连续的重复确认$，就将相应的报文段$立即重传$，而不是等该报文段的超时重传计时器超时再重传。

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

---

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

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

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

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

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

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

---

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

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

表明：“我现在希望收到的是 3 号报文段，但是我没有收到 3 号报文段，而是收到了未按序到达的报文段”

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

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

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

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

---

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

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

表明序号到 $6$ 为止的报文段都正确接收了

• 这样就不会造成对 $3$ 号报文段的超时重传
• 而是提早进行了重传

‘

---

使用快重传可以使整个网络的吞吐量提高约 $20\%$

2.2.2、快恢复算法

发送方一旦$收到3个重复确认$，就知道现在只是丢失了个别的报文段。

• 于是不启动慢开始算法，而$执行快恢复算法$

$发送方将慢开始门限\text{ssthresh}值和拥塞窗口\text{cwnd}值调整为当前窗口的一半;开始执行拥塞避免算法$

也有的快恢复实现是把快恢复开始时的拥塞窗口 cwnd 值再增大一些，即等于新的 $\text{ssthresh}+3$。

• 既然发送方收到 $3$ 个重复的确认，就表明有 $3$ 个数据报文段已经离开了网络;

• 这 $3$ 个报文段不再消耗网络资源而是停留在接收方的接收缓存中;

• 可见现在网络中不是堆积了报文段而是减少了 $3$ 个报文段。因此可以适当把拥塞窗口扩大些。

2.3、整体曲线图

3、习题

答案 C

4、小结