TCP 拥塞控制与传输优化：慢启动、拥塞避免、CUBIC 与 BBR 全解析

发送窗口约束：
  实际发送量 ≤ min(拥塞窗口 cwnd, 接收窗口 rwnd)
                    └ 网络容量（探测）┘  └ 接收方能力（对端通告）┘

关键指标：
  带宽延迟积 BDP = 带宽 × RTT    （链路"在途"最大数据量）
  例：100Mbps × 50ms → 0.625 MB ≈ 40 个 MSS
  若 cwnd < BDP → 带宽永远打不满（经典"高带宽长链路"问题）

慢启动规则：
  初始 cwnd = 初始窗口（Linux 默认 10 个 MSS）
  每收到一个 ACK，cwnd 增加一个 MSS  →  cwnd 每个 RTT 翻倍
  效果：指数增长，快速逼近链路可用带宽
  直到 cwnd ≥ ssthresh → 进入拥塞避免

为什么叫"慢"启动：
  相比早期协议一上来就塞满窗口，慢启动是从小窗口"试探"
  实际增速反而很快（指数），命名源于历史上下文
  丢失检测：超过 RTO 未收到 ACK → 认为网络拥塞

// 概念演示：慢启动 cwnd 指数增长（每 RTT 翻倍）
cwnd := 10.0
for cwnd < ssthresh {
    cwnd *= 2       // 10→20→40→80...
    if cwnd >= ssthresh {
        break
    }
}
// 进入拥塞避免后：每 RTT 只加 1 个 MSS（线性）

进入拥塞避免后：
  每 RTT 增加 1 个 MSS（线性增长，慢而稳）
  一旦检测到丢包 → cwnd 减半（乘性减小）
  丢包是"拥塞信号"，用减半回应而非归零，保持吞吐

AIMD（加增乘减）：
  加法增大：cwnd += 1 MSS / RTT
  乘法减小：遇丢包 cwnd = cwnd × 0.5（ssthresh 同步为一半）
  特点：逼近网络容量时两侧震荡，收敛于可用带宽附近

快速重传（Fast Retransmit）：
  收到 3 个重复 ACK（dup ACK）→ 直接重传丢包，不必等 RTO 超时
  原理：重复 ACK 说明后面的段已到、中间的段丢了

快速恢复（Fast Recovery）：
  超时重传后 → cwnd = 1（跌回慢启动）← 最坏情况
  重复 ACK 触发时 → ssthresh = cwnd/2，cwnd = ssthresh + 3
  恢复过程中尽量不跌回慢启动，吞吐损失更小

算法演进：
  Reno：经典 AIMD，一次恢复
  New Reno：多包丢失时避免窗口来回跌
  SACK：精确告知对端哪些段丢了，恢复更快

CUBIC 核心理念：
  增长基于"距上次丢失事件的时间 t"，而非 RTT 次数的线性
  即使用 RTT 波动大的链路，也能稳定地占领带宽附近
  在高 BDP 链路上表现远优于 Reno

窗口曲线（三次函数）：
  W(t) = C × (t - K)³ + Wmax
  其中 K = ∛(Wmax × β / C)
    Wmax：上次发生拥塞时的窗口
    β = 0.3  （乘性减小因子）
    C = 0.4  （增长曲率，与按 BDP 相关）

行为特征：
  离开上次拥塞时快速增长（凹区间）
  接近上次窗口高峰 Wmax 附近增长放缓（凸区间）
  对 RTT 波动不敏感，多流共享时更公平

传统算法（CUBIC/Reno，丢包感知）：
  以「丢包」为拥塞信号 → 窗口太大丢包就减半
  问题：在缓冲很深的网络（bufferbloat）里，
  cwnd 被排队占满后才丢包，延迟高、抖动大
  （"丢包才发现拥塞"，为时已晚）

BBR（Bottleneck Bandwidth and Round-trip time）：
  以「实测带宽 + 最小 RTT」为信号，不主动追丢包
  发送速率贴近瓶颈带宽，不人为在队列里堆数据
  → 吞吐高、延迟低、排队少

发送速率 ≈ 瓶颈带宽（BBR 的核心）
  PROBE_BW 阶段周期探测带宽变化，维持高位
  PROBE_RTT 阶段收缩到最小 RTT，避免排队误判

BBR 四个状态：
  1. STARTUP：指数增发探测瓶颈带宽（类似慢启动）
  2. DRAIN：发现瓶颈后降低发送速率，排空多余队列
  3. PROBE_BW：周期性探测带宽变化，保持高位吞吐
  4. PROBE_RTT：周期性用最小 RTT 校准，防止排队误导

落地启用：
  sysctl net.ipv4.tcp_congestion_control=bbr
  内核需 ≥ 4.9
  常见发行版已支持（内核 4.9+ 均内置）

# 查看当前拥塞控制算法与可用算法
sysctl net.ipv4.tcp_congestion_control
cat /proc/sys/net/ipv4/tcp_available_congestion_control

# /etc/sysctl.conf 常用调优项
# ---- 缓冲区与窗口 ----
net.ipv4.tcp_rmem = 4096 65536 33554432   # 读缓冲 min default max
net.ipv4.tcp_wmem = 4096 65536 33554432   # 写缓冲
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_sack  = 1                     # 选择性确认，改善乱序恢复

# ---- 拥塞控制与特性 ----
net.ipv4.tcp_congestion_control = bbr      # 或 cubic
net.ipv4.tcp_fastopen = 3                  # TFO：TLS/HTTP 首个往返携带数据
net.ipv4.tcp_mtu_probing = 1               # MTU 黑洞自动降级探测
net.ipv4.tcp_ecn = 1                       # 显式拥塞通知（可选，需对端支持）

# ---- 队列与连接 ----
net.core.somaxconn = 4096                  # 监听队列上限（配合应用 backlog）
net.ipv4.tcp_max_syn_backlog = 4096        # SYN 队列
sysctl -p

排查步骤：
  1. 用 iperf3 测瓶颈带宽 B
  2. 用 ping 测 RTT → BDP = B × RTT
  3. ss -tin 查看当前 cwnd 与发送速率
  4. 若 cwnd 长期远小于 BDP → 窗口/缓冲不够，调大 rmem/wmem
  5. 若速率贴近 B 但延迟高 → 是排队/拥塞，优先切 BBR 或降缓存

常见误区：
  - 盲目调大所有缓冲 → 内存浪费 + 延迟上升
  - 只看带宽不看 RTT → 高 BDP 链路的"假满"
  - 只顾内核不顾应用 → 应用读得慢，窗口照样坍缩

□ 高 BDP 链路优先启用 BBR（内核 4.9+），先做 A/B 对比
□ 确认 rmem/wmem 上限 ≥ BDP（带宽 × RTT 的在途字节）
□ 长连接应用配 keepalive 与合理缓冲，不让窗口复位
□ 排查"打不满带宽"时先算 BDP，再动参数
□ 用 ss -tin、iperf3 做真实测量，不靠猜
□ 压测看带宽 + P99 延迟双维度，别只看吞吐
□ TFO/ECN 等新特性灰度验证后推广
□ 网络优化先从"减少丢包与排队"入手，再调参数

TCP 用窗口探测网络，丢包感知（CUBIC）看拥塞减半，
BBR 看带宽与延迟贴近瓶颈；先测 BDP 再调参数。