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

ポリサーによる超過分の破棄 Traffic policing

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

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

通信事業者の料金プラン、クラウドインスタンスの上限、DDoS対策機器は、決められた速度を超えるパケットをキューに入れずにすぐ破棄することもあります。

なぜ 瞬間的な送信量が許容速度・許容バーストを超える → すると 超えたパケットをキューに入れずにすぐ破棄（ポリシング） → 画面では バーストが大きい瞬間ごとに複数のパケットが消え、止まった後に早送り、平均速度は上限を下回って見える

症状

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

要因

パケットロス

誰に起きるか

サーバー全体, 特定の地域・ISP, 自分だけ

いつ

人が集中したとき, 夜のピーク時間帯

担当

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

ゲーム開発チームの対応

ティックごとにまとめて送る量をティック内に分けて送り、瞬間的な送信量を許容バースト以下に下げる、秒間パケット数の上限に引っかかるなら1ティック分のメッセージを1つのパケットにまとめる。

インフラチームの対応

ネットワーク：機器のポリサー超過カウンターを確認、ポリサーの代わりにシェーパーを使う、許容バーストを増やす。サーバー機器・OS：クラウドの上限超過メトリクス（AWSならethtool -Sのbw_out_allowance_exceeded・pps_allowance_exceeded）を確認、上位のインスタンスタイプへの変更、サーバーでのペーシング（Linuxのfqキュー）。

数値の目安

シェーパー（キューに入れて遅らせる）は遅延を増やし、ポリサー（すぐ破棄）はパケットロスを増やします。TCPのゲーム接続はパケットロス1回で数百ms止まることがあるため、上限を少し超える程度なら、たいていはポリサーのほうが影響が大きくなります。

グラフでは

上限で頭打ち · 短い間隔での送信量、ポリサー・allowance超過カウンター

確認箇所

ポリサーが設定された機器の超過（exceed）・破棄カウンターを確認し、クラウドならethtool -Sのbw_out_allowance_exceeded・pps_allowance_exceededを確認。パケットロスが起きた接続は、ss -tiのrttやパケットキャプチャでロス直前のRTTを確認

該当する場合

超過カウンターが増え、短い間隔で見た送信量がある値で切り取られたように平らになっている。パケットロスの直前にRTTが上がらず、バーストが大きい瞬間にだけ複数のパケットが一度に消える

該当しない場合

パケットロスの直前にRTTが先に上がればキューあふれ（「ボトルネックでのキューあふれ」「送信バーストによる浅いバッファのあふれ」）。超過カウンターが変わらなければ別の原因

確認手段

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

出典

1. RFC 2475: An Architecture for Differentiated Services IETF
   シェーピングはパケットを遅らせてトラフィックプロファイルに合わせ、ポリシングはプロファイルを超えるパケットを破棄するという定義
2. An Internet-Wide Analysis of Traffic Policing Google
   ポリシングがかかった転送はパケットロス率が平均6倍高く、ペーシング・シェーピングで同じ目的を達成できる。ポリシングはRTTを増やさずに超過分を破棄し、キューあふれはパケットロスの前にRTTが上がるという区別（SIGCOMM 2016）
3. Monitor network performance for ENA settings on your EC2 instance AWS
   ethtool -Sのbw_out_allowance_exceeded・pps_allowance_exceeded：インスタンスの上限を超えたため、キューに入れられたか破棄されたパケット数
4. tc-fq(8) — Linux manual page iproute2
   Linuxのfqキューによる接続ごとのペーシング
5. ss(8) — Linux manual page iproute2
   ss -iのrtt（平均往復時間）

あわせて読みたい原因

同じ層：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・端末

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