5.8 TCP的拥塞控制

思维导图：

 

5.8 TCP的拥塞控制

5.8.1 拥塞控制的一般原理

• 资源与需求： 网络中资源（带宽、缓存、处理能力）是有限的。拥塞发生在需求超出资源能够提供的范围。

• 性能下降： 当多个资源同时供不应求时，网络性能下降，整体吞吐量减少。

• 解决方法的困难： 单纯增加资源（缓存、带宽、处理速率）并不一定能解决拥塞问题，有时反而会加剧。

• 复杂性： 拥塞是由多种因素引起的复杂问题，可能因各部分不匹配而导致系统整体性能受限。

• 恶化趋势： 拥塞往往自我加剧，如路由器缓存不足导致丢包，进而引起重传，加重拥塞。

• 与流量控制的区别： 拥塞控制是全局性的，防止过多数据入网导致路由器或链路过载；流量控制是端到端的，控制发送速率以免接收端不堪重负。

拥塞控制的机制与影响

• 代价： 需要收集网络流量信息，结点间需交换信息以选取和实施控制策略，导致额外开销。

• 资源分配： 可能需要将资源（如缓存、带宽）分配给个别用户，影响资源共享。

• 策略设计： 设计拥塞控制策略时要权衡利弊，确保效益最大化。

吞吐量与负载关系

• 负载（Offered Load）： 单位时间内输入给网络的分组数目。

• 吞吐量（Throughput）： 单位时间内从网络成功输出的分组数目。

• 吞吐量变化： 理想状态下，吞吐量随提供的负载线性增加，直至资源饱和。超出饱和点，吞吐量保持不变或下降。

关键点

• 拥塞控制要求全局视角，协调各部分资源。

• 策略设计需考虑成本、效益和系统整体性能。

• 理解拥塞控制的实质帮助设计更高效的网络传输策略。

 我的理解：

1. 拥塞的定义： 在计算机网络中，拥塞是指对网络中某一资源（如带宽、缓存、处理能力）的需求超过了该资源的可用容量。这种情况下，网络性能会恶化，体现在延迟的增加和吞吐量的下降。

2. 为什么增加资源不总是解决方案： 单纯地增加网络资源（例如，增加带宽或提高路由器的处理速度）并不能保证解决拥塞问题，因为可能存在的问题是资源分配不当或者是网络的各个部分之间协调不良。

3. 拥塞的复杂性和恶化趋势： 拥塞问题复杂，多因素叠加。例如，路由器缓存不足时，会导致数据包丢弃，进而引起发送方的重传，反而增加了网络负载。这种情况下，拥塞自我加剧，形成恶性循环。

4. 拥塞控制与流量控制的区别： 拥塞控制是一个全局的过程，涉及整个网络，目标是防止过多数据注入网络，避免路由器或链路过载。而流量控制是点对点的控制，即端到端之间的控制，确保发送端的发送速率不会使接收端超载。

5. 拥塞控制的成本和代价： 实施拥塞控制需要收集网络状态信息，可能需要在网络结点之间交换控制信息，这些都会产生开销，并可能影响网络性能。

6. 资源分配和共享： 有时候拥塞控制需要对资源进行特殊分配，这可能会影响到网络的公平性和资源的有效共享。

7. 吞吐量与负载的关系： 在理想状态下，随着网络负载的增加，吞吐量应该线性增加直至达到资源饱和点；超过饱和点后，吞吐量会保持不变或下降，因为部分数据包开始丢失。

更加形象的理解：

想象一下，你在玩一个模拟城市建设的电脑游戏，你的目标是保持城市的交通流畅。这个城市的道路网就像互联网，而每辆车就好比一个数据包。城市的道路有它的容量限制，也就是带宽；而交通信号灯和停车场则相当于网络中的路由器和缓存。

现在，让我们用这个比喻来深入理解TCP拥塞控制的各个方面：

1. 拥塞控制的一般原理：

• 就像你的城市如果有太多的车辆同时上路，超出了道路的容纳能力，交通就会拥堵。如果网络中的数据包数量超出了网络资源（带宽、缓存、处理能力）的处理能力，就会发生网络拥塞。

2. 资源需求大于可用资源：

• 想象一下早高峰时刻，每个人都想开车去上班，街道变得非常拥挤，因为车辆的数量远远超过了道路的容纳量。这就像网络中的数据需求超出了可用资源，导致数据包延迟甚至丢失。

3. 增加资源并非万能：

• 如果你试图通过建设更多的道路来解决交通问题，可能会发现这不仅成本高昂，而且可能根本无济于事。更多的道路可能导致更多的车辆涌入，最终仍然会拥堵。同样地，在网络中简单地增加带宽或缓存可能并不会解决拥塞问题，有时甚至会让情况更糟。

4. 系统的各部分需要平衡：

• 你的城市交通系统需要平衡：信号灯要合理控制流量，道路要有适当的容量，停车场要有足够的空间，这样交通才能流畅。网络系统也是一样，需要所有部分都协调工作，以避免瓶颈和拥堵。

5. 拥塞控制与流量控制：

• 城市中的拥堵通常是广泛的问题，需要综合策略来缓解。而对于单个司机来说，他只需要关注自己的速度，确保不会撞上前车就好。在网络中，拥塞控制是一个全局过程，需要所有的设备协同工作；而流量控制则是端到端的问题，确保发送方不会淹没接收方。

通过这个模拟城市的比喻，我们可以更直观地理解TCP拥塞控制的复杂性和必要性，它就像城市中的交通管理系统一样，旨在维持数据流的流畅和高效。

1. 理想拥塞控制：

   • 目标：使网络吞吐量达到最大。
   • 假设：网络资源分配总能适应需求，无延迟丢包。

2. 实际拥塞控制：

   • 观察：随着负载增加，吞吐量先增加后减少。
   • 现象：在吞吐量达到峰值之前，就已经有数据包丢失。
   • 轻度拥塞：吞吐量小于理想状态，开始有丢包现象。
   • 严重拥塞：负载继续增加导致吞吐量下降。
   • 死锁：负载过多导致网络完全瘫痪，吞吐量为零。

3. 拥塞控制策略：

   • 增大资源：比如增加带宽、建设更多链路。
   • 减少需求：比如限制新连接，要求用户减少数据发送。
   • 考虑：拥塞控制措施带来的其他影响。

4. 拥塞控制难题：

   • 动态问题：网络状态持续变化，控制策略需要动态调整。
   • 分组丢失：常是拥塞的征兆，而不是原因。

5. 拥塞监测指标：

   • 丢包率、队列长度、超时重传、时延及其标准差等。

6. 拥塞控制方法：

   • 开环控制：设计时预防拥塞，无运行时调整。
   • 闭环控制：实时反馈调整，包括监测、传递拥塞信息、调整策略。
   • 系统稳定性：避免频繁或迟缓的响应引起的系统不稳定。

7. 实践困难：

   • 系统复杂性：需要控制理论来理解和设计拥塞控制。
   • 时间常数选择：既不能太快也不能太慢，需找到平衡点。

 我的理解：

1. 吞吐量：就像是一条公路的车流量，网络吞吐量是指在一定时间内网络能成功传送数据的量。

2. 理想的拥塞控制：想象一个交通系统在任何时候都能自动适应车流量，绝不会发生拥堵。在理想状态下，网络能够处理其最大容量的数据流量，没有任何延迟或数据丢失。

3. 实际的拥塞控制：在现实中，网络就像城市道路一样，可能因为车辆过多导致交通减速甚至停滞。网络在承载过多数据时会导致速率下降，甚至出现数据包丢失（就像交通事故导致车辆堵塞）。

4. 拥塞的发展：一开始是轻度拥塞，类似于高峰期的交通变慢，但随着负载继续增加，网络可能进一步陷入严重拥塞，最终导致死锁，就像交通彻底停止，车辆无法前进。

5. 拥塞控制策略：对应到交通系统，这就像是增加道路、扩宽车道（增大资源），或者是限制车辆上路（减少需求）来解决拥堵问题。

6. 动态问题：网络拥塞控制不是一次性的解决方案，而是需要根据实时流量动态调整的过程。

7. 拥塞监测：网络拥塞监测就像是监控道路交通流量的传感器，它可以检测网络中的延迟和数据包丢失。

8. 开环与闭环控制：

   • 开环控制：就像是在设计城市时就规划了足够的道路和桥梁来避免未来可能出现的拥堵。
   • 闭环控制：更像是实时交通监控系统，它通过摄像头、传感器等实时收集交通状况，并通过信号灯、限速等措施动态调整交通流。

9. 实践困难：由于网络和交通系统的复杂性，拥塞控制的实际应用需要精心设计，既不能反应过激也不能反应迟缓，以保持网络的稳定性和效率。

简而言之，网络拥塞控制就是一种确保网络流量顺畅的机制，它需要动态调整，随着网络状况的变化而变化。

5.8.2 TCP的拥塞控制方法

概念

TCP拥塞控制是一种机制，目的在于防止过多的数据同时在网络中传输，从而避免网络拥堵。

四种算法

1. 慢开始（Slow Start）
2. 拥塞避免（Congestion Avoidance）
3. 快重传（Fast Retransmit）
4. 快恢复（Fast Recovery）

拥塞控制背景

• 数据单向传输，对方只传送确认报文。
• 接收方有足够缓存空间，发送窗口大小由网络拥塞程度决定。

慢开始和拥塞避免

• 基于窗口的拥塞控制。
• 维护拥塞窗口（cwnd）状态变量，其大小取决于网络拥塞程度。
• 当网络无拥塞：增大cwnd，发送更多分组。
• 当网络有拥塞：减小cwnd，减少分组数。

拥塞窗口大小变化

• 初始cwnd：
  • SMSS > 2190字节 => cwnd = 2 × SMSS，最大2个报文段。
  • 1095 < SMSS ≤ 2190字节 => cwnd = 3 × SMSS，最大3个报文段。
  • SMSS ≤ 1095字节 => cwnd = 4 × SMSS，最大4个报文段。
• 慢开始增长：
  • 对于每个收到的确认，cwnd 增加一个SMSS。
  • 拥塞窗口cwnd每次的增加量=min(N, SMSS)，其中N是新确认的字节数。

传输轮次（Transmission Round）

• 表示发送所有cwnd允许的报文段并收到最后一个字节确认的往返时间RTT。
• 慢开始算法中，每个轮次结束后cwnd加倍。

注意点

• “慢”指的是开始时cwnd从1开始逐渐增长，而非增长速度慢。
• 实际运行中，TCP不必等到轮次结束就可以增大cwnd并发送新报文段。

 我的理解：

TCP拥塞控制的目的：

TCP拥塞控制旨在避免过多的数据包同时在网络中传输而导致的网络拥塞。拥塞控制的核心是调整发送方发送数据的速率，以避免网络拥堵，确保数据能够高效、稳定地传输。

四种主要的拥塞控制算法：

1. 慢开始（Slow Start）：这是一个启动阶段的算法，用于探测网络的容量，逐渐增加网络中的数据量，而不是一开始就发送大量数据。
2. 拥塞避免（Congestion Avoidance）：当网络接近其承载极限时，该算法用于逐步增加网络流量，避免产生拥塞。
3. 快重传（Fast Retransmit）：当发送方收到三个重复的确认时，立即重新发送丢失的数据包，而不是等待超时事件。
4. 快恢复（Fast Recovery）：在快重传后调整拥塞窗口的大小，尝试快速恢复到网络拥塞前的传输速率。

拥塞窗口（cwnd）：

拥塞窗口是TCP拥塞控制中的一个关键变量，它限制了没有收到确认的最大数据量。cwnd的大小根据网络条件动态变化，反映了网络的拥塞程度。

算法原理：

• 慢开始算法：
  • 在TCP连接开始时，拥塞窗口（cwnd）从1或更小的值开始，并在每次收到确认时加倍，快速增长直到遇到网络拥塞的迹象。
• 拥塞避免：
  • 当cwnd达到某个阈值后，算法转为线性增长，即每个RTT只增加一个MSS的大小，这样避免因为窗口增长过快导致的拥塞。

往返时间RTT和传输轮次：

RTT是一个数据包从发送到被确认的往返时间。传输轮次指的是在一段时间内发送出所有数据包并收到确认的过程。慢开始算法使用传输轮次的概念来翻倍拥塞窗口的大小。

总结概念的理解：

理解这一节，关键在于掌握TCP如何根据网络条件调整数据传输速率来防止网络拥塞。开始时，TCP通过慢开始算法慎重地增加其发送速率，避免一上来就造成拥塞。一旦发现网络条件允许，它就通过拥塞避免算法继续保持稳定而谨慎的增长。当检测到丢包时，快重传和快恢复算法允许TCP迅速响应，减少超时重发的等待时间，并尽可能地保持连接的吞吐量。通过这些措施，TCP能够有效地利用网络资源，同时避免因为过载而造成的拥塞崩溃。

我们可以用“公路交通管理”作为类比来形象解释TCP的拥塞控制方法：

慢开始（Slow Start）

想象一下，一个新的公路刚刚开放，交通管理部门不确定承载能力，因此他们决定采用“慢开始”的策略。一开始，只允许一辆车进入，如果这辆车顺利通过，没有引起拥堵，那么下次就允许两辆车进入，然后是四辆，逐渐加倍，就像在没有堵车迹象时加速放行车辆一样。这样，车辆的流量慢慢增加，直到遇到交通拥堵的迹象。

拥塞避免（Congestion Avoidance）

当公路的交通达到了一个平衡点，车流量较大但是还没有拥堵时，交通部门转换策略到“拥塞避免”。这时，他们不再加倍允许车辆进入，而是更加谨慎地一次只多放一辆车，避免交通量突然增加造成拥堵。

快重传（Fast Retransmit）

设想如果有一辆车因为某种原因停在了公路中间，这将会引起交通拥堵。通常交通监控中心可能会等待一段时间看情况是否自己解决，但是在“快重传”策略下，一旦监控到这种情况，交通管理部门会立即派出救援队伍帮助那辆车尽快移动，以防止更严重的交通堵塞。

快恢复（Fast Recovery）

当那辆故障车辆被处理掉之后，交通管理部门知道公路并没有完全堵塞，所以不需要从头再来，而是继续从当前的车流量继续慢慢增加车辆，直到再次达到流量平衡点。

通过这个公路交通的比喻，我们可以看到TCP拥塞控制方法在监控和调节数据流量方面就像是在合理调度一条繁忙公路上的车辆流量，以保持数据传输的流畅并避免网络拥堵。

TCP拥塞控制笔记

1. 目的：防止cwnd（拥塞窗口）增长过快造成网络拥塞。

2. 慢开始门限ssthresh：

   • ssthresh 是转换拥塞控制行为的阈值。
   • 初始设置为16个报文段。
   • cwnd < ssthresh：慢开始算法。
   • cwnd > ssthresh：拥塞避免算法。
   • cwnd = ssthresh：可选择慢开始或拥塞避免算法。

3. 拥塞避免算法：

   • 目标：让cwnd线性增长（加法增大AI），非指数级。
   • 每个RTT（往返时间）cwnd增加1个MSS（最大报文段大小）。

4. 拥塞避免示例（图5-25）：

   • cwnd从1开始，指数增长直至ssthresh。
   • 超时时，ssthresh设置为cwnd/2，cwnd重置为1，重新慢开始。
   • 线性增长直至再次遇到网络问题。

5. 快重传：

   • 目的：尽早发现单个报文段的丢失，避免超时。
   • 实现：接收方立即发送重复ACK。
   • 发送方收到3个重复ACK时，立即重传丢失报文段。

6. 快恢复：

   • 当确认丢失个别报文段时，不完全回退到慢开始。
   • ssthresh 设置为cwnd/2，cwnd设置为ssthresh或ssthresh + 3×MSS。
   • 继续拥塞避免算法。

7. 版本差异：

   • 提到TCP Reno版本区别于早期的TCP Tahoe。

8. 注意事项：

   • 一些实现细节可能有所变化，例如ssthresh的计算方法。
   • 丢包不一定意味着网络拥塞。

我的理解：

这段文本主要介绍了TCP协议中的拥塞控制机制，重点讲解了慢开始（Slow Start）、拥塞避免（Congestion Avoidance）、快重传（Fast Retransmit）和快恢复（Fast Recovery）四种算法。这些算法的目标是通过动态调整网络数据传输的速率来防止网络拥塞。笔记的核心点可以概括为：

1. 慢开始（Slow Start）:

   • cwnd（拥塞窗口）初始化为1。
   • 当cwnd < ssthresh（慢开始门限）时，每收到一个ACK，cwnd加1，实现指数增长。
   • ssthresh的初始值通常较大，例如本文设为16个报文段。

2. 拥塞避免（Congestion Avoidance）:

   • 当cwnd >= ssthresh时，启用拥塞避免算法。
   • cwnd以线性增长，每个RTT（往返时间）增加1个MSS（最大报文段大小）。
   • 拥塞避免的增长速率比慢开始时的增长速率慢。

3. 超时（Timeout）:

   • 当网络超时，认为网络出现拥塞。
   • 调整ssthresh为cwnd/2，cwnd重置为1，重新开始慢开始算法。

4. 快重传（Fast Retransmit）:

   • 当发送方连续收到3个对同一个报文段的重复确认时，立即重传丢失的报文段而不等待超时。
   • 这有助于快速恢复丢失的报文段，并且避免因为超时误判为网络拥塞。

5. 快恢复（Fast Recovery）:

   • 快重传之后，不直接进入慢开始，而是将ssthresh设置为cwnd/2，cwnd设置为ssthresh或ssthresh加上一定数量的MSS，然后进入拥塞避免状态。
   • 这样做是因为接收到重复ACK表示有数据已到达接收方，网络不一定拥塞。

6. 版本差异:

   • 文中提到的是TCP Reno版本，它与老版本的TCP Tahoe在快恢复算法上有所不同。
   • TCP Reno在快恢复期间仍然增加拥塞窗口，而TCP Tahoe在收到重复ACK时会将拥塞窗口减半。

7. 注解说明:

   • 实际应用中，拥塞窗口的增加是以字节为单位，而不是报文段数量。
   • cwnd的增加量是MSS * MSS/cwnd，即每个ACK只增加一小部分，保证了增长的平滑性。

TCP拥塞控制笔记

• AIMD算法

  • 加法增大 (AI): 在拥塞避免阶段，拥塞窗口 (cwnd) 线性增加。
  • 乘法减小 (MD): 出现超时或连续三个重复ACK时，门限 (ssthresh) 设置为 cwnd 的一半，cwnd 大幅减小。

• 性能提升

  • 引用[STEV94][RFC 5681]，采用AIMD明显改进了TCP性能。

• 拥塞控制流程图(图5-27)

  • 比特例图5-25更全面。
  • 包括慢开始、拥塞避免、发生超时或三个重复ACK的处理。

• 流程图关键点

  • 连接建立时，cwnd=1，启动慢开始。
  • 慢开始中，cwnd 按指数规律增加直到等于 ssthresh。
  • 超时或收到三个重复的ACK时，更新 ssthresh 为 cwnd/2，cwnd 减小。

• 发送方和接收方窗口 (Flow Control)

  • 假定接收方有无限缓存空间，但实际上接收方窗口 (rwnd) 有限。
  • 发送方窗口由接收方窗口 (rwnd) 和拥塞窗口 (cwnd) 决定。

• 发送方窗口上限 (式5-9)

  • 发送方窗口上限值 = Min [rwnd, cwnd]。
  • 接收能力或网络拥塞控制发送速率，取决于 rwnd 和 cwnd 中较小的值。

---

图5-27提供了一个更完整的TCP拥塞控制视图，包括慢开始、拥塞避免、以及应对网络事件的行为。在此基础上，说明了如何通过两个不同类型的窗口（rwnd和cwnd）结合来控制数据的发送速率，既要考虑到接收方的能力，也要考虑到网络当前的拥塞情况。这种机制帮助TCP达到高效和稳定的数据传输。

5.8.3 主动队列管理(AQM)

核心概念：

• AQM与TCP拥塞控制紧密相关。
• 路由器的分组处理策略对TCP拥塞控制有显著影响。

问题识别：

• 长处理时间引起TCP重传，可能导致误判网络拥塞。
• 路由器尾部丢弃策略（FIFO队列满时丢弃新到分组）会触发全局同步现象。

全局同步现象：

• 导致多个TCP连接同时减速，造成网络通信量剧烈波动。

主动队列管理AQM：

• 提前采取行动以避免队列满时的尾部丢弃，减少全局同步。
• 通过智能管理而非简单的尾部丢弃来优化网络性能。

随机早期检测(RED)：

• 一种曾广泛使用的AQM算法。
• 基于两个参数：最小门限和最大门限，控制分组的丢弃。
• 操作：
  • 平均队列长度小于最小门限：排队。
  • 平均队列长度大于最大门限：丢弃。
  • 平均队列长度介于两者之间：按概率p丢弃。

RED的挑战：

• 确定合适的丢弃概率p。
• RFC 2309原推荐RED，但RFC 7567已声明其陈旧，不再推荐。

现状与未来：

• 没有一种AQM算法成为IETF标准。
• RED已被其他算法所取代，但仍在实验阶段。
• 关注AQM的新进展。

 我的理解：

1. TCP拥塞控制与网络层策略的联系：

   • TCP拥塞控制主要是在传输层处理拥塞问题，但网络层的处理策略（如路由器的分组丢弃策略）对其有直接影响。

2. 尾部丢弃策略的问题：

   • 传统的FIFO路由器队列管理在队列满时采用尾部丢弃策略，这会造成新到达的分组被丢弃，可能引发TCP误判网络拥塞，并进行不必要的拥塞控制措施。
   • 这种情况下的连锁反应可能导致多个TCP连接几乎同时减速（全局同步），引起网络通信量的大幅波动。

3. 主动队列管理（AQM）：

   • AQM提出的目的是为了优化网络的响应于拥塞情况，而不是等到队列满了才开始丢弃分组。
   • 通过提前丢弃分组来发出网络拥塞的预警，这可以减轻拥塞程度或者完全避免发生拥塞。

4. 随机早期检测（RED）：

   • RED作为一种实现AQM的策略，它通过设置最小和最大的队列长度门限，并根据平均队列长度来确定分组的丢弃概率。
   • 当队列长度适中时，RED通过随机概率丢弃分组，避免了尾部丢弃策略可能导致的全局同步现象。

5. RED的挑战与发展：

   • 确定丢弃概率p是RED的复杂部分，因为这个概率不是固定的，而是需要动态计算。
   • 尽管RED曾被推荐用于互联网中的路由器，但后续的实践表明它的效果并不理想，故在RFC 7567中被标记为过时，并不再推荐使用。

6. AQM的未来：

   • 虽然现在没有一个标准的AQM算法，RED也被其他算法所取代，但主动队列管理的概念依然是网络管理中的一个重要组成部分。
   • 新的AQM算法仍在研究和测试中，这需要持续关注以了解最新进展。

我的理解：

1. TCP拥塞控制： 类比于城市交通信号灯系统。信号灯根据车流量的增减自动调整绿灯持续的时间，以避免交通拥堵。如果车辆太多，信号灯会缩短绿灯时间，减少通过路口的车辆数，以防止交叉路口堵塞。

2. 尾部丢弃策略： 想象一个停车场只有限定的停车位，当停车场满了之后，新来的车辆不得不离开。在网络中，当路由器的数据包队列满时，新到达的数据包会被丢弃，就像是没有足够的停车位给新来的车辆。

3. 主动队列管理（AQM）： 类比于一个交通系统，其中的管理者能预见到交通拥堵的迹象，例如车辆流量增加。在达到拥堵点之前，他们通过调整信号灯，或者通过电子信息板提前告知司机可能的延误，并建议减速或改道。这种做法避免了交通的突然停滞。

4. 随机早期检测（RED）： 类似于警察随机在路上设置检查点，暂时停止某些车辆行驶。这不是为了完全阻止流量，而是为了发送一个警示给司机，让他们知道前方可能会有拥堵，从而鼓励他们放慢速度或提前寻找其他路线。

5. RED的挑战与发展： 假如交通警察之前采取的随机检查措施并不总是有效，有时可能导致不必要的延误或混乱。他们可能会寻找更加精细的管理方法，比如基于实时交通数据来调整信号灯的策略。

6. AQM的未来： 交通管理者正在试验各种先进的管理技术，比如使用智能交通系统和预测软件，这些系统可以根据实时数据调整路网流量，并通过移动应用通知司机最佳路线，以缓解拥堵。

通过交通管理的比喻，我们可以更直观地理解网络中的AQM如何在数据包开始排队时预测拥堵，并采取主动措施来减缓或避免拥塞现象，以确保数据流动的顺畅。

 总结：

重点：

1. 慢启动（Slow Start）：

   • TCP连接开始时搜索带宽的快速方式。
   • 拥塞窗口（cwnd）从1个MSS（最大段大小）开始，每收到一个确认（ACK），cwnd加倍。

2. 拥塞避免（Congestion Avoidance）：

   • 当cwnd达到慢启动阈值（ssthresh），进入线性增长阶段。
   • 防止网络进入拥塞状态。

3. 快速重传（Fast Retransmit）：

   • 接收到3个冗余ACK时，立即重传丢失的包，不必等待重传计时器到期。

4. 快速恢复（Fast Recovery）：

   • 进行拥塞窗口的调整以快速恢复传输。

难点：

1. 确定合适的慢启动阈值（ssthresh）：

   • 这通常需要对网络的实际性能有一定的了解，而这个了解很难仅通过观察单一的TCP连接获得。

2. 准确识别网络拥塞：

   • TCP使用丢包作为网络拥塞的信号，但丢包也可能由于其他原因（如链路错误）引起。

3. 拥塞窗口调整策略：

   • 必须在提供高吞吐量和避免拥塞之间找到平衡点。

易错点：

1. 混淆慢启动和拥塞避免阶段：

   • 这两个阶段的窗口增长策略不同，应清楚当前所处的阶段。

2. 不当处理超时和重传：

   • 必须准确实施快速重传和快速恢复，避免不必要的超时和重传。

3. 误将路由器队列延迟当作拥塞信号：

   • 路由器队列的延迟增加并不总是意味着网络拥塞。

4. 对全局同步的理解不足：

   • 忽视了尾部丢弃策略可能导致多个TCP连接同步减少窗口大小，引发全局同步问题。

5. 忽视网络环境变化：

   • 网络条件可能随时间变化，静态的拥塞控制参数可能不适应动态网络环境。

6. 对AQM机制的理解不足：

   • 忽略了AQM对于提前预防网络拥塞的作用，而依然采用简单的尾部丢弃策略。

在实际应用中，为了优化TCP的拥塞控制性能，通常需要根据网络状况和应用需求进行细致的参数调整，并配合现代网络设备使用先进的AQM算法。理解上述的重点、难点和易错点对于设计和维护高效的TCP网络至关重要。