ゲームラグ白書 › L8 ソケットとプロトコル
UDPパケットのIPフラグメンテーション IP fragmentation of large UDP
原因ID sk-fragment · 主担当 ゲーム開発チーム・サーバー開発
図と実験のあるメインページでこのカードを開く →
MTU（一度に送れるサイズ）を超えるUDPパケットはIP層でフラグメント化され、フラグメントを1つ失うだけでパケット全体が破棄されます。
なぜ 人の多い場所のスナップショットが1,500バイトを超える → すると 複数のフラグメントに分割して送信、1つでも失うと全体を破棄 → 画面では 大きなパケットほどロス率が数倍になる。混雑した場所でだけワープ
- 症状
- ワープ
- 要因
- パケットロス
- 誰に起きるか
- 特定の場所・チャンネル, 特定の地域・ISP
- いつ
- 人が集中したとき
- 担当
- 主担当 ゲーム開発チーム・サーバー開発
- ゲーム開発チームの対応
- パケットを1,200バイト以下に自前で分割、変更分だけを送る。
- 数値の目安
- ロス率2%の回線では、4つのフラグメントに分かれたパケットの約8%が失われます。フラグメント化されたパケットを一律に破棄するファイアウォールや通信事業者もあり、その場合ユーザーは大きなパケットを1つも受け取れません。
- グラフでは
- 人数・負荷に連動して上昇 · IPフラグメンテーションの数（IpFragCreates）、スナップショットのサイズ
- 確認箇所
- サーバーでnstat -azのIpFragCreates（送信時に作ったフラグメント数）の増加量を確認し、受信側ではIpReasmFails（再構築の失敗数）を確認。ゲームサーバーのログやパケットキャプチャでUDPパケットのサイズ分布を確認
- 該当する場合
- 人が集中する場所でIpFragCreatesが増え、1,500バイトを超えるUDPパケットがあり、そのときワープの報告が増えている
- 該当しない場合
- IpFragCreatesが増えなければ、サーバーの送信側ではフラグメンテーションは起きていない
- 確認手段
- インフラのツールで確認（ゲームコード不要）
出典
- RFC 8085: UDP Usage Guidelines IETF
フラグメントを1つ失うと再構築できずパケット全体を失う、UDPアプリはIPフラグメンテーションを避けるべき - RFC 8900: IP Fragmentation Considered Fragile IETF
ファイアウォールや一部のネットワークがIPフラグメントを破棄する事例 - net/ipv4/proc.c (Linux v6.12) Linux kernel
nstatが表示するカウンター名：IpグループのFragCreates（作ったフラグメント数）・ReasmFails（再構築の失敗数）
あわせて読みたい原因
同じ層：L8 ソケットとプロトコル
同じ症状（ワープ）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る