TCP 拥塞控制核心机制：从慢启动到 BBR

本文拆解 TCP 如何"猜"出可用带宽：经典四阶段算法的演进逻辑、丢包作为信号的局限，以及 BBR 为什么会把规则重写一遍。

为什么需要拥塞控制？

没有拥塞控制的世界：
  所有发送端都拼命往网络灌 → 路由器队列爆满 → 大面积丢包
  →  everyone 重传 → 更堵 → 拥塞崩溃（1986 年 Internet 就真实发生过全局吞吐骤降）

TCP 的任务：在"不知道链路容量"的前提下，自己试探出能跑多快，
           并且不比邻居贪心（公平性），也不把中间设备压垮。

两个约束合起来决定发送窗口：
  cwnd（拥塞窗口）—— 网络还能吃多少
  rwnd（接收窗口）—— 对方缓冲还剩多少
  实际发送量 = min(cwnd, rwnd)

经典四阶段（Reno 视角）

      0                                          带宽上限
  发送速率 ↑            拥塞避免（加法增）/\/\/\ 丢包
                      /
                    /
          指数增 ↑ /
      慢启动  / ↗（到 ssthresh 转折）
             /
            └──────────────────────────────▶ 时间
                     超时丢包 → 慢启动从头再来

1. 慢启动（Slow Start）
   cwnd 从初始值（通常 10 MSS / ~14KB）开始
   每收到一个 ACK → cwnd += 1 MSS → 每 RTT 翻倍（指数增长）
   不是"慢慢传"，而是"先小步快探"，因为不知道链路能扛多少

2. 拥塞避免（Congestion Avoidance）
   cwnd ≥ ssthresh 后：每 RTT 只 +1 MSS（加法增）
   指数→线性的转折目的：逼近容量时放慢试探速度

3. 快速重传（Fast Retransmit）
   收到 3 个重复 ACK → 不等超时立刻重传丢的那段
   （3 个 dupACK 说明后面的包都到了，只是中间掉了一个）

4. 快速恢复（Fast Recovery）
   丢包后 cwnd 减半、ssthresh = cwnd/2，从一半继续线性增
   Reno：超时则 cwnd 打回 1 重新慢启动（代价极狠）

核心哲学：AIMD（加法增、乘法减）——线性增长保证公平收敛，
乘性下降保证大家"一起退让"，这是 Reno/CUBIC 家族的公共底座。

队列视角：Bufferbloat 与丢包信号

经典算法把"丢包"当网络拥塞的唯一信号，但现代网络有两个干扰项：

1. 随机丢包（无线误码、光路抖动）
   → 算法误判为拥塞，无谓降速

2. 缓冲膨胀（Bufferbloat）
   路由器队列很深：不丢包，但 RTT 从 10ms 涨到 300ms
   → cwnd 一路飙，延迟爆炸，吞吐反而变差（视频通话卡死的主因）

问题本质：靠"等爆队"来探测带宽 = 用高延迟换吞吐
于是出现两条改良路线：
  A. 更早、更细地看拥塞征兆（ECN、延迟梯度）
  B. 直接建模测带宽（BBR）

各算法一览

CUBIC 直觉

丢包后从 W_max 按 cubic 曲线回升：
  离 W_max 远 → 增得快（快速恢复）
  接近 W_max → 平台期微增（探测是否还能更高）
  超过后 → 缓慢回落稳定
好处：增长节奏与 RTT 解耦（长肥管道不再吃亏），
      高带宽下吞吐恢复极快，因此成为 Linux 默认。

BBR：把"猜丢包"换成"量带宽"

BBR（Google，2016；BBRv2 2019 改公平性）不再等丢包，而是持续估计两个物理量：

BtlBw  = 链路瓶颈带宽（近几个 RTT 交付速率的最大值）
RTprop = 最小往返时延（近 200s 内 RTT 最小值，≈ 纯传播延迟）

目标：发送量 = BDP = BtlBw × RTprop
      在"刚好填满管道、不填队列"的点全速跑

 pacing gain 控制每个时片的发送速率；
 cwnd 上限 = BDP × 2（只防超大队列）

状态机

START      慢启动（用 2.88 的高增益快速拉满，按丢包或
             "增长<2%"判据退出，而非等队满丢包）
  ↓
DRAIN      把慢启动灌多的排队清掉（gain 1/2.88），降到 RTT 回落
  ↓
PROBE_BW   稳态：以 1 倍带宽巡航，周期内一轮 gain=1.25 超发探测
           （4 个 RTT 维持 + 1 个 RTT 探测）
  ↓
PROBE_RTT  长期没看到更低的 RTT → 限时压到 4 个 packet 的极小量，
           排空队列重新量一次"干净" RTprop，然后回 PROBE_BW

BBR 的强项与争议

强项：
  - 有损/随机丢包链路（WiFi、跨洋）不再被误判降速
  - 低延迟下高吞吐（不把队列当缓存用）
  - 对 shallow buffer 友好，缓解 bufferbloat

争议（v1 为主）：
  - 与丢包型算法共存时会"抢占"队列（公平性吃亏/占便宜双面）
  - 对整形器（token bucket 限速）可能测不满突发而低估带宽
  - 与 ECN/QoS 设备行为交互有坑
v2 改进：降 gain 1.25→1.13、对 ECN 标记更敏感、引入损失上限与
         主动 fairness 信号，收敛更接近传统算法。

工程落地备忘

# Linux 启用
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq        # 必须 fq/fq_codel（pacing 靠它）
ss -ti -p                          # 观察 delivery rate / rtt_min
常见误区：只开 bbr 不配 fq；容器里 sysctl 没生效；
        短连接场景收益有限（还没到 PROBE_BW 就结束了）

实战：怎么判断该用哪种

总结

理解 TCP 拥塞控制的关键在于：传统算法是"以丢包为唯一反馈的分布式猜测游戏"，优点是简单公平、缺点是拿延迟和队列当筹码；BBR 换了范式——把网络当可测量的物理系统，用交付速率和最小 RTT 建模出 BDP 并贴着上限跑，代价是需要 fq 这类精准 pacing 与更复杂的公平性补丁。