壅塞控制造成傳送量驟降 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 很充足仍然積壓時，要查接收端視窗（「Zero window（看起來像重傳的停頓）」）或伺服器傳送端
確認方式: 用基礎設施工具確認（不需要遊戲程式碼）

出處

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 值：listen socket 是等待 accept 的連線數與 backlog 上限；已連線的 socket 是應用程式尚未讀取的位元組數與尚未收到 ACK 的已送出位元組數