輻輳制御による送信量の急減 Congestion control backoff

原因ID sk-congestion · 主担当 インフラチーム・サーバーインフラ · 副担当ゲーム開発チーム・サーバー開発

TCPはパケットロスを輻輳のシグナルとみなし、送信速度を30〜50%落とします。Wi-Fiでのパケットロスにも同じように反応します。

なぜ送る量が多いときに、Wi-Fiや回線でわずかなパケットロスが発生 → すると TCPが送信速度を大きく落とし、ゆっくり回復（Linux・WindowsのデフォルトであるCUBICは30%落とす） → 画面では 人の多い場所で更新が遅れて早送り・入力遅延

症状: 早送り, 入力遅延
要因: 遅延, ストール
誰に起きるか: 自分だけ
いつ: 人が集中したとき
担当: 主担当 インフラチーム・サーバーインフラ · 副担当ゲーム開発チーム・サーバー開発
ゲーム開発チームの対応: 送る量を減らす（関心領域、変更分だけ）、一度にまとめて送らないよう分けて送る。
インフラチームの対応: 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の値：リッスンソケットではacceptを待っている接続数とbacklogの上限、接続済みソケットではアプリがまだ読んでいないバイト数とACKを受け取っていない送信バイト数