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

経路変更・ECMPの不良経路 Route change / bad ECMP member

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

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

インターネットの経路が切り替わる数秒の間、または複数のECMP経路のうち不良な経路に割り当てられた接続で、パケットが消えます。

なぜ BGPの経路再計算、または複数の経路（ECMP・LAG）のうち1つの経路で機器・回線が不良 → すると 経路の切り替え中に一時的なパケットロス、またはその経路を通る接続だけに継続的なパケットロス → 画面では 突然数秒止まった後に早送り、または「再接続すると直る」（別の経路に割り当てられる）

症状

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

要因

パケットロス

誰に起きるか

特定の地域・ISP

いつ

ときどきランダムに

担当

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

ゲーム開発チームの対応

接続ごとの再送統計（TCP_INFO）を記録し、症状が出ている人のIP・ポートと時刻を抽出できるようにする、数秒止まった接続をすぐに切断しない。

インフラチームの対応

地域・通信事業者ごとの再送率を監視、再接続で経路が変わるかを確認、複数の通信事業者の回線を確保、自社機器のECMP・LAG経路のうち不良リンクを点検、経路の測定もゲームと同じTCPポートで行う（mtr --tcp --port。経路はアドレス・ポートで決まるため、通常のpingは別の経路を通って正常に見えることもある）。

外部の対応

通信事業者に、同じTCPポートで測った経路の測定結果と再接続前後の比較を添えて、不良経路を報告。

グラフでは

ある時点から階段状に上昇 · RTT（Ping）、地域・通信事業者ごとの再送率

確認箇所

bcc tcpretrans -cで再送を接続ごとに集計し、症状が出ているユーザーのアドレス・ポートを抽出。サーバーからユーザー側へ、ユーザー側からサーバーへ、ゲームと同じTCPポートでmtr（mtr -T -P PORT）を取って比較。再接続の前後の結果も比較

該当する場合

ある時刻を境に、特定の地域・通信事業者のRTTが階段状に変わって数秒間パケットロスが集中する。または同じ通信事業者の中でも一部の接続（アドレス・ポートの組み合わせ）だけが継続的に再送し、再接続すると直る。通常のpingは正常なのに、TCPのmtrでだけパケットロスが見えることもある

該当しない場合

その通信事業者のすべての接続が夜のピークにそろって悪化するなら「ボトルネックでのキューあふれ」。1人のユーザーだけが悪く、ルーターまでのpingからパケットロスがあるなら「無線区間のパケットロス」

確認手段

インフラのツールで確認（ゲームコード不要）

実際の事例

Cloudflare 2020: Cloudflareのバックボーン設定ミスで一部都市のトラフィックが途絶

出典

1. RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection IETF
   マルチパスではping・tracerouteのような診断ツールの結果を信頼しにくいことと、フローをハッシュして経路を固定する方式の説明
2. RFC 2992: Analysis of an Equal-Cost Multi-Path Algorithm IETF
   ECMPは、フローを識別するヘッダーフィールドのハッシュで次の経路を選ぶ（同じフローは同じ経路）
3. tcp(7) — Linux manual page Linux man-pages
   TCP_INFO：ソケットごとの状態（struct tcp_info）を取得
4. mtr(8) manual page source mtr
   -T（--tcp）はICMPの代わりにTCP SYNを使い、-P（--port）は宛先ポートを指定
5. Demonstrations of tcpretrans, the Linux eBPF/bcc version IO Visor
   再送ごとに相手のアドレス・ポートを1行ずつ表示し、-cはフローごとの再送数を集計

あわせて読みたい原因

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

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

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

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

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