tcp_recovery_slow如何慢恢复

本文目录导读：

1. 它是在什么场景下工作的？
2. 它是如何“慢”恢复的？
3. 举例说明（数值简化版）
4. 设计目的与适用性
5. 总结一句话：

在TCP拥塞控制中,tcp_recovery_slow（通常指慢恢复阶段的慢启动或特定的恢复机制）的核心思想是：在丢包发生后，不要激进地降低发送速率，也不要立即恢复到拥塞前的速率，而是通过一个“慢速恢复”的过程，逐步探测网络当前的承载能力。

与传统的快速恢复相比,tcp_recovery_slow 强调更保守和更平滑的速率增长，以减少再次丢包的风险。

它是在什么场景下工作的？

通常发生在：

• 拥塞通知（ECN，Explicit Congestion Notification） 被标记时。
• 检测到轻微拥塞（如RTT抖动、早期丢包）而非严重重传超时（RTO）。
• 某些特定拥塞控制算法（如CUBIC、BIC、BBR的慢启动退出后）中，作为激进恢复的替代方案。

它是如何“慢”恢复的？

与标准快速恢复相比,tcp_recovery_slow 的核心差异在于拥塞窗口（cwnd）的调整策略。

具体机制通常包括：

1. 更低的阈值 (ssthresh)： 将慢启动阈值设置得更低（例如减少到当前窗口的70%甚至50%以下），这迫使恢复阶段从一个更低的起点开始，避免立即对网络造成压力。
2. 更保守的窗口增长： 在恢复阶段，每收到一个确认（ACK），拥塞窗口cwnd不是按标准的“每个RTT增加1个MSS”，而是按照更小的增量（如每2个RTT增加1个MSS，或使用更小的增益因子）。
3. 延迟退出： 可能会让连接在恢复阶段停留更长时间（例如等待更多的重复ACK或确认），才切换到正常的拥塞避免模式。
4. 使用RTT反馈： 结合实时测量的RTT，如果RTT仍在持续增加，则进一步放缓甚至暂停窗口增长（类似于BBR的“瓶颈带宽探测”阶段）。

举例说明（数值简化版）

假设当前 cwnd = 100 MSS，检测到丢包：

• 传统快速恢复：

  1. ssthresh = 50 MSS
  2. cwnd = 53 MSS
  3. 每个ACK增加 1 / 50 ≈ 0.02 MSS
  4. 很快恢复到50 MSS以上，并继续线性增长。

• tcp_recovery_slow：

  1. ssthresh = 35 MSS（更保守的减半）
  2. cwnd = 35 MSS（无额外+3等激进补偿）
  3. 每个ACK增加 1 / 70 MSS ≈ 0.014 MSS（增长更慢）
  4. 在恢复期间,如果检测到持续拥塞（如RTT上升），则抑制增长。
  5. 退出后,可能以比传统拥塞避免更慢的速率（如斜率为0.8而非1.0）开始增长。

设计目的与适用性

• 目的： 减少抖动和缓冲区bloat，在高速网络或延迟敏感的链路（如实时音视频、物联网）中，缓慢恢复可以显著降低丢包概率和延迟峰值。
• 代价： 速度恢复更慢，吞吐量暂时下降，不适合对突发流量容忍度高的场景。

总结一句话：

tcp_recovery_slow 通过设置更低的窗口阈值、更慢的增长斜率以及对RTT更敏感的控制，让TCP在丢包后像一个“谨慎的司机”一样，缓慢而稳定地试探网络容量，而不是像“传统快速恢复”那样立刻加速。

如果你是在特定内核或协议栈中看到这个术语（如FreeBSD的TCP栈或某些Linux TCP BBR变种），具体实现参数可能不同，但这个核心思想是通用的。

标签： tcp_recovery_slow 慢恢复