한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

アイドル後のスロースタート Slow start after idle

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

TCPはしばらくアイドル状態が続くと輻輳ウィンドウ（一度に送れる量）を再び縮めるため、急に大きなデータを送るときに何回かに分けて送ります。

なぜアイドル状態だった接続で、街への入場など大きなデータを送る → すると 輻輳ウィンドウが縮んでいるため、複数の往復に分けて送信 → 画面では 入場直後、周りのキャラクターやNPCが往復数回分遅れて表示される（遠いサーバーほど目立つ）

症状: 入力遅延, 表示されない・ゴースト
要因: 遅延
誰に起きるか: 自分だけ
いつ: 移動中・マップ切り替え時, しばらく放置した後
担当: 主担当 インフラチーム・サーバーインフラ · 副担当ゲーム開発チーム・サーバー開発
ゲーム開発チームの対応: 入場時のデータを減らす（どうしても必要なものから先に送る）。
インフラチームの対応: tcp_slow_start_after_idleを無効にする（Linux、サーバー全体の設定）。
数値の目安: RTOより長くアイドル状態が続くと輻輳ウィンドウが縮み始め、長くアイドルだった場合は約14KB（パケット10個）まで下がります。そうなると100KBは一度に送れず、3往復に分けて送ることになります。
グラフでは: 一部だけ高い · 入場直後の送信時間（RTTが長いユーザー）
確認箇所: sysctl net.ipv4.tcp_slow_start_after_idleの値を確認し、アイドル後にエリアへ入場した瞬間、その接続のss -tiでcwnd（輻輳ウィンドウ）が小さくなっているかを確認
該当する場合: 設定が1（デフォルト）で、アイドル後の入場の瞬間にcwndが10前後まで縮み、送信が複数の往復に分かれる。RTTが長いユーザーほど遅れて表示され、0に変えると解消する
該当しない場合: cwndが大きいまま維持されているのに遅れて表示されるなら、サーバー側の入場処理（「密集エリア進入時のスポーン集中」）
確認手段: インフラのツールで確認（ゲームコード不要）

出典

IP Sysctl Linux kernel
tcp_slow_start_after_idleはデフォルトで有効、RTOの間アイドルなら輻輳ウィンドウを縮める（RFC 2861の方式）
RFC 5681: TCP Congestion Control IETF
RTOより長くデータを送っていなければ、輻輳ウィンドウをリスタートウィンドウmin(IW, cwnd)以下に縮めてスロースタート
RFC 6928: Increasing TCP's Initial Window IETF
初期ウィンドウは10セグメント、最大14,600バイト
ss(8) — Linux manual page iproute2
-iのcwnd（輻輳ウィンドウ）・ssthresh（スロースタートのしきい値）

あわせて読みたい原因

同じ層：L8 ソケットとプロトコル

同じ症状（入力遅延）を起こすほかの層の原因

大人数の描画負荷 L1 クライアントのゲームプロセス
メインスレッドのパケット処理ボトルネック L1 クライアントのゲームプロセス
V-Syncとレンダーキュー L1 クライアントのゲームプロセス
省電力モード・サーマルスロットリング L2 クライアントのOS・端末
同じ端末の他のアプリによる帯域幅の占有 L2 クライアントのOS・端末
ディスプレイ・入力デバイス・フレーム生成による遅延 L2 クライアントのOS・端末
Wi-Fiチャンネルの混雑 L3 家庭内ネットワーク
バッファブロート（ルーターのキュー） L3 家庭内ネットワーク

図と実験のあるメインページでこのカードを見る