拥塞控制导致发送量骤降 Congestion control backoff

原因 ID sk-congestion · 主责 运维团队·系统运维 · 配合研发团队·服务器开发

TCP 把丢包当作拥塞信号，把发送速率降低 30~50%。遇到 Wi-Fi 丢包也会同样降速。

起因要发送的量大时，Wi-Fi 或线路上出现少量丢包 → 结果 TCP 大幅降低发送速率，然后缓慢恢复（Linux、Windows 默认的 CUBIC 降低 30%） → 画面表现 人多的地方更新积压，表现为快进、操作延迟

症状: 快进, 操作延迟
因素: 延迟, 停顿
谁会遇到: 只有我
何时出现: 人多的时候
负责方: 主责 运维团队·系统运维 · 配合研发团队·服务器开发
研发团队要做的事: 减少发送量（AOI 过滤、只发变化部分）；分散发送，避免一次性集中发出。
运维团队要做的事: 改用 BBR 等拥塞控制算法（tcp_congestion_control）。
监控图上: 缓慢上升后骤降 · 每个连接的拥塞窗口（cwnd）、发送速率
查看位置: 对更新积压的玩家连接多次执行 ss -ti，看 cwnd、ssthresh 的变化和拥塞控制算法名（cubic、bbr），同时看 Send-Q 是否在堆积
确认依据: 丢包后 cwnd 大幅下降再缓慢回升，反复出现；下降期间 Send-Q 堆积，与快进、操作延迟的反馈时间重合
排除依据: cwnd 充足却仍积压，看接收方窗口（“零窗口（看起来像重传的停顿）”）或服务器发送侧
确认手段: 运维工具即可确认（无需游戏代码）

出处

RFC 9438: CUBIC for Fast and Long-Distance Networks IETF
CUBIC 在丢包时把窗口降为 0.7 倍（降低 30%），Reno 降为 0.5 倍；CUBIC 是 Linux、Windows、Apple 的默认算法
TCP BBR congestion control comes to GCP – your Internet just got faster Google Cloud
基于丢包的拥塞控制在非拥塞原因造成的丢包时也会大幅降低发送速率；BBR 依据传递速率和 RTT 判断
IP Sysctl Linux kernel
用 tcp_congestion_control 选择新连接的拥塞控制算法
ss(8) — Linux manual page iproute2
-i 的 cwnd、ssthresh 和拥塞控制算法名
net/ipv4/tcp_diag.c (Linux v6.12) Linux kernel
ss 的 Recv-Q、Send-Q 值：监听 socket 上是等待 accept 的连接数和 backlog 上限，已连接 socket 上是应用尚未读取的字节数和已发送但尚未收到 ACK 的字节数