Congestion Control

Tahoe、Cubic、BBR——都是 拥塞控制算法。它们决定了网络传输速度如何上升、下降、以及如何在拥塞时自我调整。

1. Tahoe：早期的 TCP 拥塞控制算法

TCP Tahoe（1988 左右） 是最早成体系的拥塞控制算法之一，它引入了几乎所有现代算法的基础机制：

📌 核心机制

• 慢启动（Slow Start）
  初始发送窗口很小（cwnd=1），每收到一个 ACK 就指数增长。
• 拥塞避免（Congestion Avoidance）
  窗口线性增长，而不是指数增长。
• 超时后 cwnd 直接回退到 1
  非常保守。

👍 优点

• 简单、安全、不容易压垮网络。

👎 缺点

• 太保守，丢包后速度恢复非常慢。
• 已基本不再用于现代互联网。

---

2. Cubic：Linux 默认的 TCP 拥塞控制算法

TCP Cubic（2005） 是现代互联网中最常用的 TCP 拥塞控制算法之一（Linux 默认）。

📌 核心思想

Cubic 用一个 三次函数（立方） 来决定窗口增长，而不是线性或指数。

• 网络空闲时增长速度快（利用高带宽链路）
• 接近拥塞点时增长慢（避免过度冲击）
• 丢包后的恢复速度比 Reno/Tahoe 快得多

👍 优点

• 高速网络（高带宽高延迟，比如光纤）表现非常好
• 稳定，友好，部署广泛

👎 缺点

• 基于“丢包即拥塞”的假设，在高丢包但并不拥塞的网络表现较差（例如 Wi-Fi、移动网络）

---

3. BBR：Google 的下一代拥塞控制算法

BBR（Bottleneck Bandwidth and RTT） 是 Google 提出的新算法，在 GCP、YouTube、QUIC 等大量场景使用。

它和传统 TCP 完全不同：

📌 核心思想

• 不再把“丢包”当作拥塞信号
• 而是主动测量：
  • 瓶颈带宽（B）
  • 最小 RTT（R）
• 试图让发送速率 ≈ 网络实际能承载的速率

也就是 基于模型（model-based）而不是基于丢包（loss-based）。

👍 优点

• 在高丢包网络表现极好
• 非常高效（YouTube 的速度显著提升）
• 能充分利用带宽且延迟低

👎 缺点

• 对传统 TCP（Reno/Cubic）不太公平（BBR 容易“抢带宽”）
• 需要配合 QUIC/TCP 栈进行优化

---

🧩 这些算法和 HTTP/3 的关系？

HTTP/3 运行在 QUIC 上，不是 TCP。
QUIC 拥塞控制算法可以选择 Cubic、BBR，甚至自定义算法。

QUIC 默认实现通常包括：

• Cubic（最常用）
• BBR（常见于 Google/Cloudflare 实现）

Tahoe 基本不会出现在 QUIC 中。

---

📝 总结表

名称	类型	核心机制	优点	缺点	时代
Tahoe	早期 TCP	慢启动+线性增长+丢包回到1	安全	太慢太保守	1988
Cubic	TCP/QUIC 常用	三次函数增长	高带宽表现好	对丢包敏感	2005–至今
BBR	现代 TCP/QUIC	通过测量带宽 & RTT	速度快、延迟低、抗丢包	对其他流不完全公平	2016–至今

---

如果你愿意，我还可以继续讲：

• BBR v2 的改进
• Cubic 函数的数学形式
• 它们在 QUIC/HTTP3 中的实际实现方式
• 或如何在 Linux 上切换这些算法

只要告诉我你想深入到什么程度 🚀