ゲームラグ白書 › TCP再送の根本原因

無線区間のパケットロス Wi-Fi / cellular link loss

原因ID rt-wireless · 主担当 外部・外部 · 副担当 インフラチーム・サーバーインフラ, ゲーム開発チーム・サーバー開発, ゲーム開発チーム・クライアント開発

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

Wi-Fiとモバイル回線は、無線区間で何度か再送し、それでも届かなければパケットを破棄します。破棄されたパケットは、TCPがかなり後になってから送り直します。

なぜ 電波が弱いか干渉が強く、無線区間での送信が連続して失敗 → すると 無線機器の再試行上限（通常は数回〜十数回）を超えるとパケットを破棄 → 画面では TCPの再送を待つ間止まり、後続のパケットは受信バッファで待たされた後に早送り

症状

フリーズ, 早送り, ワープ

要因

パケットロス, ジッター

誰に起きるか

自分だけ, 同じ家

いつ

ときどきランダムに, 移動中・マップ切り替え時

担当

主担当 外部・外部 · 副担当 インフラチーム・サーバーインフラ, ゲーム開発チーム・サーバー開発, ゲーム開発チーム・クライアント開発

ゲーム開発チームの対応

サーバー：TCP_NODELAYを有効にする（Nagleアルゴリズムが有効だと、RACKがロス判定に使う後続パケットがない）、再送で詰まっている間に送る状態更新はためずに最新のものだけ送る（カーネルにたまる量はTCP_NOTSENT_LOWATで制限）。クライアント：TCP_NODELAYを有効にする（自分の入力方向のパケットロスはクライアントOSが回復）、パケットロスが集中したりPingが急上昇したりしたら画面にネットワーク状態を表示。

インフラチームの対応

RACK-TLPでロス回復を速くする（サーバーは無線区間のパケットロスを防げず、できるのは回復を速くすることまで）、最新Linuxのデフォルト値であるnet.ipv4.tcp_recovery=1（RACK）・net.ipv4.tcp_early_retrans=3（TLP）が変更されていないか確認。

外部の対応

ユーザーに、有線接続、5GHz・6GHzの利用、ルーターの設置場所・チャンネルの変更を案内。

数値の目安

無線区間のパケットロスが1%なら、ゲームのパケット100個のうち1個が消えます。1秒に10個受信するなら、10秒に1回ほどの割合でカクッと止まります。RACK-TLPがなければ、そのたびにRTO（Ping + 200ms以上）の間止まります。

グラフでは

一部だけ高い · 接続ごとの再送率、接続ごとのRTT（Ping）

確認箇所

ユーザーのPCからルーター（ゲートウェイ）のアドレスとゲームサーバーにそれぞれpingを数百回送ってパケットロスと遅延の幅を比較し、有線やモバイルデータに切り替えて再測定。サーバーではss -tiでそのユーザーの接続のretransとrtt（平均/偏差）を確認

該当する場合

ルーターまでのpingですでにパケットロスやばらつく遅延が見られ、有線に切り替えると消える。サーバーから見ると、そのユーザーの接続だけretransとRTTの偏差が大きい

該当しない場合

ルーターまでは問題がなく、その先からパケットロスが始まるなら通信事業者・経路側（「ボトルネックでのキューあふれ」「経路変更・ECMPの不良経路」）。同じ通信事業者の複数のユーザーが同時に悪化するなら、通信事業者の区間から確認

確認手段

ユーザー側の環境で確認

もっと詳しく

無線機器の再試行はジッターを生み（再試行ごとに数ms）、再試行上限を超えた場合だけがパケットロスになります。そのため無線の品質が悪くなるほど、「ジッター → ときどき止まる → 頻繁に止まる」の順に症状が大きくなります。アクセスポイント（AP）の間を移る瞬間（ローミング）には、数十ms〜数秒の間、続けてパケットを失うこともあります。モバイル回線は基地局との区間で多く再送するため、パケットロスよりも数百msの遅延の急上昇として現れることが多くなります。

実際の事例

Square Enix 2021: FINAL FANTASY XIVの拡張パッケージ発売時の混雑とログイン待機列のエラー

出典

1. net/wireless/core.c Linux kernel
   Linuxの無線スタックのデフォルトの再試行上限：短いフレーム7回、長いフレーム4回（dot11ShortRetryLimit・dot11LongRetryLimit）
2. RFC 3481: TCP over Second (2.5G) and Third (3G) Generation Wireless Networks IETF
   モバイル回線はリンク層の再送のおかげでIPレベルのパケットロスは少ないが、その回復がジッターと遅延の急上昇として現れる
3. Wi-Fi roaming support in Apple devices Apple
   APを移るときは新しいAPでの認証が終わるまでデータを送れず、802.1X環境では数秒かかることがある
4. RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP IETF
   RACK（時間に基づくロス判定）とTLP（末尾パケットの再送）の定義
5. IP Sysctl Linux kernel
   tcp_recoveryのデフォルト値0x1（RACK）、tcp_early_retransのデフォルト値3（TLP有効）、TCP_NOTSENT_LOWAT・tcp_notsent_lowatでまだ送信していないデータ量を制限
6. tcp(7) — Linux manual page Linux man-pages
   TCP_NODELAYはNagleアルゴリズムを無効にし、小さなデータもすぐに送る
7. include/net/tcp.h Linux kernel
   RTOの最小値TCP_RTO_MIN = 200ms
8. misc/ss.c iproute2
   ss -tiは、retrans:現在再送中の数/累計再送数と、rtt:RTT/RTTの偏差（rttvar）を表示

あわせて読みたい原因

同じ層：TCP再送の根本原因

• ボトルネックでのキューあふれ（輻輳によるロス）
• 送信バーストによる浅いバッファのあふれ
• ポリサーによる超過分の破棄
• 物理エラー（不良ケーブル・光モジュール・コネクター）
• デュプレックスの不一致
• 受信サーバーのホストでのパケット破棄
• ファイアウォール・接続追跡による破棄
• 中間機器の処理上限超過（ファイアウォール・IPS・DDoS対策）
• MTUブラックホール（大きいパケットだけ繰り返し失われる）
• 接続中のNAT・ロードバランサーのマッピング期限切れ
• 経路変更・ECMPの不良経路
• 遅延の急上昇による不要な再送
• 順序の入れ替わりによる不要な高速再送
• ACKの遅れ・消失（上り回線の飽和）
• RTOの設定が環境に合っていない
• thin streamの遅い回復
• 中間機器によるTCPオプションの除去
• ゼロウィンドウ（再送のように見える停止）
• 接続要求（SYN）の再送

同じ症状（フリーズ）を起こすほかの層の原因

• フレームタイムのスパイク L1 クライアントのゲームプロセス
• クライアントのガベージコレクション L1 クライアントのゲームプロセス
• メインスレッドでの同期ロード・シェーダーコンパイル L1 クライアントのゲームプロセス
• ストレージが遅くアセットストリーミングが間に合わない L1 クライアントのゲームプロセス
• ゲームのセキュリティモジュール（アンチチート）の検査 L1 クライアントのゲームプロセス
• Wi-Fi ↔ LTE・5Gの切り替え L2 クライアントのOS・端末
• クライアントのメモリ不足・スワップ L2 クライアントのOS・端末
• ビデオメモリ（VRAM）不足 L2 クライアントのOS・端末

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