# ゲームラグ白書 (Game Lag White Paper)

> オンラインゲームでラグ（カクつき、ワープ、引き戻し、早送り、入力遅延、フリーズ、切断など）が起きる原因228件を、自分の画面からサーバーのデータベースまで、13の層と3つのテーマ（同期設計、一部のユーザーだけに起きる問題、TCP再送）に分けて説明する白書です。MMOの事例を中心に書いていますが、大部分はジャンルを問わずオンラインゲーム全般に当てはまります。原因ごとに「なぜ → すると → 画面では」の3段階、関連する症状、数値の目安、解決の担当（ゲーム開発チーム・インフラチーム・外部）とチーム別の対応、グラフの形と確認方法、信頼できる出典（RFC、カーネル・OS・クラウド・エンジン・DBの公式ドキュメント、論文）を載せています。

原因はID（例：mem-gc）で指し、原因ごとにページがあります（例：https://jungrok5.github.io/mmo-lag-anatomy/ja/c/mem-gc.html）。数値は一般的なサービス環境での代表値で、デフォルト値・バージョンの根拠は各原因ページの出典にあります。引用するときは原因ページのURLを使ってください。MITライセンス。原文は韓国語で、この版はその翻訳です：https://jungrok5.github.io/mmo-lag-anatomy/

## ドキュメント

- [全文（Markdown）](https://jungrok5.github.io/mmo-lag-anatomy/ja/llms-full.txt): 原因・症状・担当・用語・出典のすべてを1ファイルに
- [テキスト版](https://jungrok5.github.io/mmo-lag-anatomy/ja/text.html): 同じ内容をJavaScriptなしで1ページで読めるHTML
- [ゲームラグ白書](https://jungrok5.github.io/mmo-lag-anatomy/ja/): 図と、実際に操作できる実験を含むメインページ

## 症状別の原因

- [カクつき](https://jungrok5.github.io/mmo-lag-anatomy/ja/s/stutter.html): 原因60件。動きが滑らかでなく、短く止まっては動くのを繰り返します。
- [ワープ](https://jungrok5.github.io/mmo-lag-anatomy/ja/s/teleport.html): 原因47件。キャラクターが途中の移動なしに、離れた位置へ一瞬で移ります。
- [引き戻し](https://jungrok5.github.io/mmo-lag-anatomy/ja/s/rubber.html): 原因14件。自分のキャラクターが前に進んでいたのに、今通ってきた位置へ引き戻されます。
- [早送り](https://jungrok5.github.io/mmo-lag-anatomy/ja/s/burst.html): 原因36件。止まっていた画面が動き出すと同時に、たまっていた動き・ヒット・ダメージが一気に早回しで流れます。
- [スローモーション](https://jungrok5.github.io/mmo-lag-anatomy/ja/s/slowmo.html): 原因24件。すべてがゆっくり動きます。スキルの発動やモンスターの移動が間延びして見えます。サーバーの設計によっては、速度はそのままでカクつき・ワープとして現れることもあります。
- [入力遅延](https://jungrok5.github.io/mmo-lag-anatomy/ja/s/delay.html): 原因76件。押してから結果が出るまでに時間がかかります。画面そのものは滑らかな場合もあります。
- [フリーズ](https://jungrok5.github.io/mmo-lag-anatomy/ja/s/freeze.html): 原因67件。画面内のすべてが少しの間（0.5秒〜数秒）止まってから、また動き出します。
- [不発・ロールバック](https://jungrok5.github.io/mmo-lag-anatomy/ja/s/dropped.html): 原因36件。確かにやったはずの行動がなかったことになるか、結果がしばらく経ってから覆ります。
- [切断](https://jungrok5.github.io/mmo-lag-anatomy/ja/s/disconnect.html): 原因51件。プレイ中に接続が切れ、ログイン画面や再接続の画面に戻されます。
- [接続不可・無限ロード](https://jungrok5.github.io/mmo-lag-anatomy/ja/s/noconnect.html): 原因45件。ゲームに入れない、またはロード・入場画面で止まったままになります。
- [表示されない・ゴースト](https://jungrok5.github.io/mmo-lag-anatomy/ja/s/invisible.html): 原因20件。いるはずのNPC・モンスター・プレイヤーが自分の画面にだけいない、またはすでに消えたオブジェクトが自分の画面にだけ残っています。

## L1 クライアントのゲームプロセス

- [フレームタイムのスパイク](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/cg-hitch.html): 1フレームの計算に普段の数倍の時間がかかり、画面が一瞬止まります。
- [クライアントのガベージコレクション](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/cg-gc.html): 使い終わったメモリ（ガベージ）を回収する間、ゲーム全体が止まります。一定の間隔でカクつくのが特徴です。
- [メインスレッドでの同期ロード・シェーダーコンパイル](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/cg-sync-load.html): 初めて見るエリア・モンスター・エフェクトを描画する直前に、ファイルの読み込みやシェーダーの生成を待って止まります。
- [ストレージが遅くアセットストリーミングが間に合わない](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/cg-asset-stream.html): HDDのような遅いストレージでは、オープンワールドのテクスチャ・モデルを読み込む速度が移動に追いつかず、オブジェクトの表示が遅れたり、ゲームが読み込みを待ってカクついたりします。
- [大人数の描画負荷](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/cg-crowd.html): 攻城戦やワールドボスのように数百人が1つの画面に入ると、描画のコストそのものが処理しきれなくなります。
- [メインスレッドのパケット処理ボトルネック](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/cg-net-mainthread.html): 受信したパケットをフレームごとに決まった量しか処理しないと、押し寄せたパケットがどんどん次のフレームへ持ち越されます。
- [補間バッファがないか短い](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/cg-no-buffer.html): サーバーのパケットを受け取ってすぐ描画すると、ジッター（到着間隔のばらつき）がそのまま画面に表れます。
- [過度な外挿（デッドレコニング）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/cg-extrap.html): パケットが届かない間は最後の速度のまま動かし続けて見せ、外れていたと分かると元に戻します。
- [クライアントサイド予測の不一致](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/cg-predict.html): 自分のクライアントが先に動かして見せたのに、サーバーの計算結果が違うと、自分のキャラクターが引き戻されます。
- [固定タイムステップの追いつき処理の暴走](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/cg-fixed-step.html): 一度止まった後、遅れた計算をまとめて処理しようとして、その計算のせいでさらに遅れます。
- [時刻同期の誤差](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/cg-clock.html): クライアントが推定したサーバー時刻がずれていると、補間のタイミングやクールタイムの判定がずれます。
- [float型で持つ時刻の精度低下](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/cg-float-time.html): ゲーム内の時刻を精度の低い小数形式（float）で持っていると、起動したままの時間が長いほど時間分解能（区別できる最小の時間差）が下がり、動きやエフェクトが震えます。
- [V-Syncとレンダーキュー](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/cg-vsync.html): GPUが描画したフレームを何枚かキューにためておき、モニターの周期に合わせて出力する間、入力が遅れます。
- [クライアントのメモリリーク](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/cg-leak.html): 長く起動しておくほどメモリが増えてだんだん重くなり、最後にはゲームが強制終了します。
- [クライアントのクラッシュ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/cg-crash.html): 処理されないエラーでゲームが終了します。プレイヤーには切断のように見えますが、サーバーは正常です。
- [ゲームのセキュリティモジュール（アンチチート）の検査](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/cg-anticheat.html): チートを防ぐためにゲームと一緒に動くセキュリティモジュールが、定期的に検査を行います。検査が重かったり、セキュリティサーバーとやり取りするハートビート（定期的な生存確認の信号）が遅れたりすると、カクついたり切断されたりします。

## L2 クライアントのOS・端末

- [バックグラウンドプロセスによるCPU占有](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/co-background.html): ウイルス対策ソフトのスキャン、Windows Update、配信ソフト、ブラウザの動画がコアを占有すると、ゲームスレッドがCPUを割り当ててもらえずに待たされます。
- [省電力モード・サーマルスロットリング](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/co-power.html): ノートPCのバッテリーモード、スマホの省電力モード、端末の発熱によって、CPU・GPUの速度が落ちます。発熱の場合は、最初は問題なく、しばらくしてから重くなるのが特徴です。
- [タイマー分解能](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/co-timer.html): Windowsのデフォルトのタイマーは15.6ms単位なので、「1msだけ待つ」が実際には次のタイマー周期まで、長いと15.6msまで延びます。
- [モバイルアプリのバックグラウンド移行](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/co-mobile-bg.html): 通知を見ようとアプリをいったんバックグラウンドに移すと、OSが数秒後にアプリを一時停止（suspend）し、その間にサーバーは自分を切断します。
- [Wi-Fi ↔ LTE・5Gの切り替え](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/co-netswitch.html): 家の外に出てWi-Fiが切れ、LTE・5Gに切り替わると、自分のIPアドレスが変わり、それまでの接続が無効になります。
- [セキュリティソフトによるパケット検査](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/co-security.html): ウイルス対策ソフト・ファイアウォールがすべてのパケットを検査すると遅延が増え、行き過ぎるとゲームを攻撃と誤認してブロックします。
- [受信バッファのあふれ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/co-rcvbuf.html): ゲームの処理が忙しく、ソケット（OSが提供するネットワーク送受信のインターフェース）からパケットを取り出すのが遅れると、OSのバッファがあふれます。
- [クライアントのメモリ不足・スワップ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/co-swap.html): ブラウザのタブを数十個開いたままゲームを動かすと、OSがゲームのメモリの一部をディスクに追い出します。
- [ビデオメモリ（VRAM）不足](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/co-vram.html): グラフィックオプションが必要とするメモリがグラフィックボードのメモリより大きいと、OSがテクスチャをPCのメモリへ追い出してはまた戻すため、カクつきます。
- [Wi-Fiのバックグラウンドスキャン](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/co-wifi-scan.html): OSが周囲のWi-Fiを探すために定期的にチャンネルを切り替えている間、通信が一瞬止まります。
- [NICの省電力・ドライバーの問題](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/co-driver.html): 有線LANアダプター・Wi-Fiチップがパケットの合間に省電力状態に入ると、再び動き出すまでに時間がかかります。
- [同じ端末の他のアプリによる帯域幅の占有](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/co-other-apps.html): クラウド同期、大容量のダウンロード、ゲームのアップデートが同じPCで動いていると、ゲームのパケットがキューで待たされます。
- [ウィンドウの最小化・非アクティブ時の処理制限](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/co-unfocused.html): ほかのウィンドウを見たりゲームを最小化したりすると、ゲームとWindowsが電力を節約するためにゲームの処理を遅くします。戻ると遅れていたパケットが押し寄せるか、すでに切断されています。
- [オーバーレイソフトの干渉](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/co-overlay.html): メッセンジャー・ランチャー・録画・FPS表示のソフトが、ゲーム画面の上に自分のUIを重ねて描くため、ゲームのレンダリング処理に割り込みます（フック）。フレームごとの処理が増え、ときどきゲームとぶつかって一瞬止まったり、ゲームが強制終了したりします。
- [ディスプレイ・入力デバイス・フレーム生成による遅延](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/co-display-input.html): Pingは正常なのに操作が重いなら、テレビの映像処理やワイヤレスコントローラー、フレーム生成機能が、入力と画面の間に遅延を上乗せしているのかもしれません。

## L3 家庭内ネットワーク

- [Wi-Fiの干渉・電波の弱さ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/hn-wifi.html): 電波が弱かったり干渉があったりすると、無線区間で何度も送り直すことになり、パケットの到着がばらつきます。
- [Wi-Fiチャンネルの混雑](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/hn-channel.html): マンションのようにルーターが数十台ある場所では、同じチャンネルを分け合って使うため、送信の機会を待つことになります。
- [バッファブロート（ルーターのキュー）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/hn-bufferbloat.html): 家族の誰かが動画をアップロードしたり大きなファイルをダウンロードしたりすると、ルーターのキューに数百ms分のパケットがたまり、ゲームのパケットもその後ろで待たされます。
- [NATマッピングの期限切れ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/hn-nat.html): ルーターは、しばらくパケットがやり取りされていないアイドル接続をNATテーブルから削除します。しばらく放置した後、動いた瞬間に切断されるときによくある原因です。
- [ルーターの性能不足・過熱](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/hn-router.html): 安価なルーターに数十台の機器、数千の接続が集中すると、ルーター自体が処理しきれなくなります。
- [基地局のハンドオーバー（移動中）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/hn-handover.html): バスや地下鉄で移動すると、基地局が切り替わる間、通信が途切れます。
- [RRC状態遷移の遅延（モバイル無線の省電力）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/hn-rrc.html): スマホはしばらく通信がないと無線接続を低電力状態に落とし、次のパケットのときに再び立ち上げるため遅れます。
- [モバイル電波の弱さ・不感地帯](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/hn-weak-cell.html): エレベーター・地下・建物の奥では、再送が増えて速度が落ち、最終的に切断されます。
- [5G↔LTEの頻繁な切り替え（5Gエリアの境界）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/hn-5g-flip.html): 5Gの電波が弱い建物の中や5Gエリアの境界では、スマホが5GとLTEを頻繁に行き来し、切り替わるたびにPingが跳ねたり通信が一瞬途切れたりします。
- [公衆Wi-Fi・社内ネットワークの制限](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/hn-captive.html): カフェのWi-Fiのログインページや会社のファイアウォールが、ゲームの接続をブロックします。

## L4 インターネット回線

- [伝搬遅延（物理的な距離）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/isp-distance.html): 光ファイバーの中では、光でさえ1秒に約20万kmしか進みません。遠いサーバーは、どれほど性能が良くても遅れます。
- [衛星インターネット（低軌道・静止軌道）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/isp-satellite.html): 衛星インターネットは電波が宇宙を往復するため、静止軌道衛星では往復だけで0.5秒を超えます。Starlinkのような低軌道衛星は普段は速いものの、経路を割り当て直す瞬間に遅延が揺れ、一瞬途切れることもあります。
- [迂回ルーティング](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/isp-routing.html): 通信事業者どうしの接続契約の都合で、近いサーバーでも遠くを回って届きます。
- [ピーク時間帯のピアリング混雑](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/isp-peak.html): 夜9〜11時ごろは動画のトラフィックが急増し、通信事業者間の接続区間（ピアリング）が混雑しやすくなります。
- [海底ケーブル・国際回線の障害](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/isp-cable.html): 海底ケーブルが切れると、修理されるまでの数週間（長ければ数か月）は遠い迂回経路を回ることになり、残った回線は混雑します。
- [BGPの経路変更・収束](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/isp-bgp.html): インターネットの経路情報が変わり、再び収束するまでの数秒〜数十秒（まれに数分）の間、パケットが失われます。
- [ECMP経路のうち1本の不良](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/isp-ecmp.html): 通信事業者やデータセンターは同じ宛先への経路を複数持ち、接続ごとに1本の経路を決めて送ります。1本の経路だけが故障すると、その経路に割り当てられた人だけにラグが出続けます。
- [通信事業者の速度制限・トラフィック管理](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/isp-shaping.html): データ使用量の上限を超えた場合や、特定のトラフィックを管理する料金プランでは、パケットが遅らされたり破棄されたりします。
- [国・通信事業者単位のUDP制限・パケット検査](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/isp-udp-block.html): 一部のネットワークでは、特定のUDPアドレス・ポートをブロックしたりUDPの速度を制限したりし、パケット検査装置が識別できないプロトコルを遮断します。UDPで通信するゲームは、そのネットワークでは接続できなかったり、頻繁に切断されたりします。
- [回線品質の不良](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/isp-line.html): 端子の接触不良や古いケーブル、モデムの異常は、継続的なパケットロスと周期的な回線断を引き起こします。
- [DNSの障害・遅延](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/isp-dns.html): サーバー名をアドレスに変換するDNSが遅かったり失敗したりすると、ログインサーバーやアップデートサーバーを見つけられません。
- [DDoSによる共有回線の飽和](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/isp-ddos-path.html): ゲーム会社や同じネットワーク内の別の宛先を狙った大量の攻撃が、共有回線を埋め尽くします。
- [通信事業者の共有IP（CGNAT）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/isp-cgnat.html): モバイル回線や一部の通信事業者では、複数の契約者が1つのIPを共有し、アイドル接続のマッピングを短時間で削除します。
- [VPN・ラグ軽減ツール経由](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/isp-vpn.html): VPNやラグ軽減ツールを使うと、パケットはその会社の中継サーバーを経由します。中継サーバーが遠かったり混雑していたりすると、かえって遅くなります。

## L5 データセンターのネットワーク機器

- [ファイアウォールのセッションテーブル飽和](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/dc-firewall.html): ファイアウォールは、通過させたすべての接続をセッションテーブルに記録して追跡します。テーブルがいっぱいになると、新しい接続を受け付けられなくなります。
- [DDoS対策の経由・誤検知](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/dc-ddos.html): 攻撃を防ぐためにトラフィックをスクラビングセンターに回すと経路が長くなり、正常なユーザーを攻撃と誤認してブロックすることもあります。
- [ロードバランサーのアイドルタイムアウト](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/dc-lb-idle.html): ロードバランサーは、アイドル状態の接続を一定時間後に削除します。ゲーム側は接続が維持されているものとみなしているうちに、切断されてしまいます。
- [クラウドのセキュリティグループによる接続追跡の期限切れ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/dc-cloud-conntrack.html): クラウドのサーバーに付いているファイアウォール（セキュリティグループ）も接続を追跡し、アイドル接続の追跡エントリは決められた時間の後に期限切れになります。ロードバランサーを通さずに直接つなぐサーバーでも、しばらく放置していたプレイヤーが切断されることがあります。
- [クラウドのNATゲートウェイの接続・ポート上限](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/dc-nat-gateway.html): プライベートサブネットのサーバーから外部（プラットフォーム認証・決済・外部API）への接続は、NATゲートウェイがアドレスとポートを変換して送り出します。同じ宛先への同時接続がゲートウェイのポート上限を超えると、新しい接続が失敗します。
- [ロードバランサーの偏り・ヘルスチェックの誤判定](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/dc-lb-imbalance.html): 接続が1台のサーバーだけに集中したり、すでに落ちたサーバーに人を送り続けたりします。
- [スイッチのマイクロバースト](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/dc-microburst.html): 複数のサーバーが同じ瞬間に数千人へ一斉にパケットを送ると、そのトラフィックが集まるスイッチポートの小さなバッファが1ms足らずであふれます。
- [データセンター回線の飽和](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/dc-uplink.html): アップデートデータの配信・ログ転送・バックアップがゲームと同じ回線を使うと、回線がいっぱいになります。
- [ネットワーク機器のフェイルオーバー](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/dc-failover.html): ルーター・ファイアウォールの1台が故障して予備機に切り替わる（フェイルオーバー）数秒の間、全員が止まります。
- [ケーブル不良・ポートエラー](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/dc-bad-cable.html): 光モジュールやケーブルが不良だと、その経路を通るパケットが一定の割合で壊れます。
- [MTUの不一致（大きなパケットだけ消える）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/dc-mtu.html): 途中の区間のMTU（一度に送れるサイズ）が小さくなっているのにサイズ超過の通知がブロックされると、大きなパケットだけが消え続けます。

## L6 サーバーのネットワークカード

- [NIC割り込みの単一コア集中](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/nic-irq.html): NICがパケット到着の割り込みを1つのCPUコアにだけ送ると、そのコアがボトルネックになります。
- [リングバッファ不足](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/nic-ring.html): NICがパケットを一時的に入れておくリングバッファが小さいと、瞬間的に集中したときにバッファがあふれて破棄されます。
- [過剰な割り込みコアレッシング](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/nic-coalesce.html): CPUの負担を減らすために、パケットをまとめてから一度に知らせると、まとめる時間の分だけ遅れます。
- [クラウドのPPS上限超過](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/nic-cloud-pps.html): クラウドのサーバーには種類ごとに毎秒のパケット数・帯域幅の上限があり、超えると黙って破棄されます。
- [NIC帯域幅の飽和](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/nic-saturate.html): 1Gbps・10Gbpsのカードを限界まで使うと、送信キューが長くなり、最終的に破棄されます。
- [仮想化オーバーヘッド・ノイジーネイバー](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/nic-noisy.html): 同じ物理サーバー上のほかの仮想マシンがネットワーク・CPUを大量に使うと、自分のサーバーの処理が不規則に遅れます。
- [クラウドホストのメンテナンス・ライブマイグレーション](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/nic-host-maintenance.html): クラウド事業者は物理サーバー（ホスト）をメンテナンスするとき、仮想マシンを別のホストに移したり（ライブマイグレーション）、一時的に止めたりします。その間はサーバー全体が止まり、止まる時間が長いと接続が切れます。
- [NICドライバー・ファームウェアの問題](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/nic-reset.html): ドライバーのバグや機能の誤動作でカードが止まり、再起動している間はすべての送受信が途切れます。
- [GRO/LROの結合待ちによる遅延](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/nic-offload.html): 複数のパケットを1つにまとめてCPUの負担を減らす機能です。設定によっては、小さなゲームのパケットが、一緒にまとめる次のパケットを少し待つことがあります。

## L7 サーバーOS（カーネル）

- [接続待ちキュー（backlog）のあふれ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/so-backlog.html): メンテ明けに数万人が同時に接続すると、カーネルの接続待ちキュー（backlog）があふれ、接続要求が破棄されます。
- [ファイルディスクリプタの上限](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/so-fd.html): 接続ごとにファイルディスクリプタ（fd。OSが開いているファイルやソケットに付ける番号）が必要ですが、1つのプロセスが開けるfdの数には上限があります。
- [カーネルのソケットバッファ不足](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/so-sockbuf.html): 送受信バッファが小さいと、バーストトラフィックが集中したときに、UDPで受信したパケットは破棄され、TCPの送信はバッファに空きがなくブロックされます。
- [スレッド過多とコンテキストスイッチ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/so-context.html): コア数よりはるかに多いスレッドを動かすと、OSがそれらを切り替えて実行するだけでCPUを消費します。
- [CPUスチール（仮想マシン）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/so-steal.html): 物理サーバー（ハイパーバイザー）が仮想マシンのCPU時間を一時的にほかの仮想マシンに回している間（CPUスチール）、ゲームサーバーが止まります。
- [コンテナのCPUスロットリング（CFSクォータ）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/so-cpu-quota.html): コンテナにCPU上限をかけると、決まった周期（通常100ms）の中でクォータを使い切った時点から、残りの時間は強制的に止められます（スロットリング）。
- [サーバーの電源管理（C-state・周波数制御）による遅延スパイク](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/so-cstate.html): 使われていないCPUコアは、電力を節約するために深い省電力状態（C-state）に入り、周波数も下げます。パケットやタイマーが来ると、復帰して周波数を上げるまでに時間がかかるため、小さなパケットの処理に遅延が加わります。
- [OOM Killer](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/so-oom.html): Linuxはメモリが尽きると、メモリを最も多く使っているプロセスを選んで強制終了します。たいていはゲームサーバーです。
- [メモリの回収・コンパクションによる停止](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/so-reclaim.html): OSがヒュージページ（huge page）を作るためにメモリをコンパクションしたり、空きメモリを回収したりしている間、プロセスが止まります。
- [システム時刻のジャンプ（NTPステップ）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/so-timejump.html): サーバーの時刻が一度に数秒前後に調整されると、システム時刻に依存するタイマーが一斉に発火したり止まったりします。
- [定期実行ジョブ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/so-cron.html): 毎日同じ時刻に動くログ圧縮・バックアップ・セキュリティスキャンが、CPUとディスクを占有します。
- [OS・カーネル・ドライバー・ファームウェアのアップデート後の性能変化](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/so-os-update.html): ゲームのコードは変わっていないのに、サーバーのOS・カーネル・ドライバー・ファームウェアをアップデートしてから遅くなるケースです。アップデートによって、デフォルト値、スケジューラー、CPU脆弱性の緩和策（mitigations）、ドライバーの動作が変わることがあります。
- [サーバーのconntrackテーブル飽和](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/so-conntrack.html): Linuxのファイアウォールがすべての接続を記録する接続追跡（conntrack）テーブルが上限に達すると、新しいパケットを破棄します。
- [サーバー間接続のエフェメラルポート枯渇](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/so-ports.html): ゲームサーバーがDBやほかのサーバーへの接続を短時間で頻繁に張っては切ると、切れた接続がしばらくポートを占有し、新しい接続を開けなくなります。

## L8 ソケットとプロトコル

- [TCPのHOLブロッキング](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sk-hol.html): TCPは順序を守るため、失われたパケットを1つ受け取り直すまで、後から届いたパケットをゲームに渡しません。
- [TCPのRTOと指数バックオフ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sk-rto.html): 再送がまた失敗するたびに待ち時間が2倍に延びるため、短い回線断が長い停止になります。
- [Nagleアルゴリズム＋遅延ACK](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sk-nagle.html): 小さなパケットをまとめて送るNagleアルゴリズムと、ACKを遅らせて送る遅延ACKがかみ合い、メッセージを分けて書き込むたびに40〜200msずつ遅延します。
- [遅いクライアントによるブロッキング送信](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sk-block-send.html): 回線の遅い1人の送信バッファが満杯なのに、ブロッキング方式（バッファに空きができるまで呼び出しが戻らない送信）で送ると、サーバーのスレッドがその1人を待ちます。
- [遅いクライアント（slow consumer）の処理ポリシー](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sk-slow-client.html): 送るデータがたまり続けるクライアントに対して、サーバーが古い更新を破棄したり接続を切ったりします。
- [keepaliveのデフォルト2時間](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sk-keepalive.html): 相手が終了の合図なしに消えると、TCPはかなり時間がたってから検知します。keepalive（アイドル接続が生きているかを確認するTCPの機能）はデフォルトで無効で、有効にしても2時間アイドル状態が続かないと確認を始めません。
- [UDPパケットのIPフラグメンテーション](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sk-fragment.html): MTU（一度に送れるサイズ）を超えるUDPパケットはIP層でフラグメント化され、フラグメントを1つ失うだけでパケット全体が破棄されます。
- [信頼性UDPの再送設定](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sk-reliable-udp.html): UDPの上に独自に作った再送ルールが保守的すぎると復旧が遅れ、攻撃的すぎると回線をさらに詰まらせます。
- [アイドル後のスロースタート](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sk-slowstart.html): TCPはしばらくアイドル状態が続くと輻輳ウィンドウ（一度に送れる量）を再び縮めるため、急に大きなデータを送るときに何回かに分けて送ります。
- [輻輳制御による送信量の急減](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sk-congestion.html): TCPはパケットロスを輻輳のシグナルとみなし、送信速度を30〜50%落とします。Wi-Fiでのパケットロスにも同じように反応します。
- [RSTによる強制終了で最後のデータが消失](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sk-linger.html): サーバーが接続を急に切ると、最後に送った案内や保存完了の通知が失われます。
- [ブロッキングI/O構造](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sk-blocking-io.html): 1つのソケットを待っている間、スレッドがほかの処理をできない構造では、人が増えるほど全体が遅くなります。
- [SO_REUSEPORTの振り分けの偏り](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sk-reuseport.html): 同じポートを複数のプロセスで分担して受け付けると、カーネルは接続ごとにアドレスのハッシュで担当プロセスを決め、その後は変更しません。担当プロセスが1つ止まると、そこに割り当てられた人だけが待たされます。
- [WindowsのUDPソケットのWSAECONNRESETエラー](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sk-udp-connreset.html): Windowsサーバーがすでに去ったクライアントにUDPを送ると、「ポート到達不能」（ICMP）の通知が返ってきます。その通知のせいで次の受信呼び出しがエラーで終わりますが、サーバーのコードがこのエラーをソケット自体の故障として扱うと、そのソケットを使っている全員が影響を受けます。

## L9 サーバーのゲームプロセス

- [ティックバジェット超過](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sp-tick-overrun.html): 1ティックの処理がバジェットを超えるとサーバーのティック周期が延び、そのエリア全体がゆっくり進んだりカクついたりします。
- [視界（AOI）計算の急増（N²）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sp-aoi.html): 誰が誰を見られるかを全員同士で比較すると、人数が10倍になったとき計算は100倍になります。
- [ブロードキャストの急増](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sp-broadcast.html): 1人の動きを、その人が見えている全員に送ると、集まった人数の2乗に比例する数の更新を送ることになります。
- [シングルスレッドのエリア過負荷（ホットスポット）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sp-hotzone.html): エリアごとに1つのスレッドが担当する構造では、1か所に人が集中すると、そのコア1つだけが100%になります。
- [ロック競合](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sp-lock.html): 複数のスレッドが同じデータを使うために1つのロックを待つと、スレッドを増やしても一度に1つずつしか実行されません。
- [デッドロック](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sp-deadlock.html): 2つのスレッドが互いに相手の取ったロックを待つと、永遠に止まったままになります。
- [ゲームスレッドの同期呼び出し](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sp-sync-call.html): ティックの途中でDBの応答やファイルの書き込みを待つと、その時間だけサーバーのゲーム進行全体が止まります。
- [メッセージキューの滞留](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sp-queue.html): リクエストが処理速度より速く届いてキューにたまると、後ろのリクエストは数秒後にやっと処理されるか、破棄されます。
- [タイマーの一斉発火](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sp-timer-burst.html): すべてのモンスターのリスポーン、すべてのバフの期限切れ、毎正時の報酬が同じティックに集中すると、そのティックだけ処理が数十倍重くなります。
- [経路探索の急増](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sp-pathfinding.html): 数百体のモンスターが同時にプレイヤーを追いかけて経路を計算すると、CPUを大きく消費します。
- [シリアライズ・圧縮のコスト](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sp-serialize.html): 送るデータをバイト列に変換して圧縮するのにもCPUを使い、人が多いとこのコストが急増します。
- [サーバークラッシュ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sp-crash.html): 未処理のエラーでサーバープロセスが落ちると、そのサーバーにいた全員が同時に切断されます。
- [スレッドプールの枯渇](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sp-threadpool.html): 処理を担うワーカースレッドがすべて遅い処理に塞がれると、新しいリクエストはいつまでも待たされます。
- [無限ループ・ロジックの暴走](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sp-infinite-loop.html): バグで1ティックが終わらないとサーバーが止まり、ウォッチドッグが強制的に再起動します。
- [1体に集中する戦闘（ワールドボス）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sp-hot-entity.html): 数百人が1体のボスを同時に攻撃すると、そのボス1体の計算が1か所に集中し、ヒット情報が見ている全員に送信されます。
- [密集エリア進入時のスポーン集中](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sp-spawn-burst.html): 人でいっぱいの街にテレポートすると、サーバーは新たに見えるようになった数百人の外見・装備・状態を一度に送らなければなりません。
- [オブジェクトの蓄積（消えずに残るアイテム・召喚物）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sp-entity-buildup.html): 消えるはずの地面のアイテム、召喚物、終わったタイマーが片付けられずにたまると、サーバーを長く稼働させるほど毎ティックの処理が増えます。
- [アップデートによるトラフィックパターンの変化](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sp-patch-traffic.html): 新しいコンテンツ・エフェクト・同期項目がパケットのサイズと頻度を増やすと、問題なく動いていたサーバーがアップデート後からMTU・帯域幅・パケット数の上限に引っかかります。

## L10 メモリ

- [サーバーGCの全停止](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/mem-gc.html): Java・C#のサーバーがガベージを回収するために全スレッドを止めている間（stop-the-world）、サーバー全体が止まります。
- [スクリプトエンジンのGC停止](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/mem-script-gc.html): C++のサーバーでも、クエスト・AI・スキルをLuaなどのスクリプトで動かしていると、スクリプトエンジンのGCが走っている間そのゾーンが止まります。
- [アロケーションの急増](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/mem-alloc.html): イベント中に一時オブジェクトを大量に生成すると、GCが普段よりはるかに頻繁に走ります。
- [メモリリーク](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/mem-leak.html): 解放されないメモリが少しずつたまり、数日後にGCの多発・スワップ・強制終了につながります。
- [GCスラッシング（ヒープの空き不足）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/mem-gc-thrash.html): 生存データがヒープの上限に近づくと、GCが走っても回収できるものがほとんどなく、GCが休みなく繰り返されます。
- [スワップ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/mem-swap.html): メモリが足りずOSが一部をディスクに退避させると、そのメモリを使うたびに1,000倍以上遅いディスクを待つことになります。
- [キャッシュミス](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/mem-cache-miss.html): データがメモリのあちこちに散らばっていると、CPUが毎回遅いRAMまで取りに行って待つことになります。
- [メモリの断片化](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/mem-fragment.html): アロケーションと解放を繰り返して空き領域が細かく分断されると、実際に使っている量よりはるかに多くのメモリを占有するようになります。
- [NUMAのリモートメモリ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/mem-numa.html): CPUが2つあるサーバーで、反対側のCPUにつながったメモリを使うとアクセスが遅くなります。

## L11 ディスク

- [同期ログ書き込み](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/dk-sync-log.html): ゲームスレッドがログを1行書くたびにディスクへの書き込み完了を待っていると、ディスクが忙しいときにゲームの進行も一緒に止まります。
- [fsyncの集中](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/dk-fsync.html): データを「確実に」ディスクに書き込むよう要求すると、ディスクによっては1回に0.1ms〜数十msかかり、要求が集中するとキューが長くなります。
- [クラウドディスクのバーストクレジット枯渇](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/dk-burst.html): 一部のクラウドディスクや小さなサーバースペックには、一時的にベースラインより速く使えるバーストクレジットがあります。忙しい時間が長引いてクレジットが底をつくと、速度が急に落ちます。
- [IOPS上限・キューの飽和](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/dk-iops.html): ディスクが1秒間に処理できる要求数を超えると、キューが長くなって遅延が急増します。
- [ディスクフル](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/dk-full.html): ログとダンプがたまってディスクがいっぱいになると書き込みが失敗し、備えがなければサーバーが落ちます。
- [バックアップ・圧縮・スキャン処理](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/dk-backup.html): 深夜のバックアップ、ログの圧縮、セキュリティスキャンがディスクを独占すると、ゲームサーバーの読み書きが詰まります。
- [サーバーの遅延ロード](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/dk-lazy-load.html): サーバーがダンジョン・マップのデータを初めて要求されたときにディスクから読むと、そのティックの間、全員が止まります。
- [コアダンプの書き出し](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/dk-coredump.html): サーバーが落ちるときに数GBのメモリをディスクに書き出すため、再起動が数分遅れることもあります。
- [HDDのシーク遅延](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/dk-hdd.html): HDDはヘッドがプラッタ上を移動する（シーク、seek）必要があるため、散らばったデータの読み書きに1回あたり10ms近くかかります。

## L12 データベース

- [インデックスのないクエリ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/db-no-index.html): インデックスがないと、条件に合う行を探すためにテーブル全体を読む必要があります（フルスキャン）。
- [ホットスポットの行ロック競合](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/db-hot-row.html): 全員が同じ行（ギルド倉庫、オークションの人気アイテム、サーバー全体のカウンター）を更新しようとすると、ロックを取れるのは1人ずつです。
- [DBのデッドロック](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/db-deadlock.html): 2つのトランザクション（ひとまとまりで処理されるDB操作）が互いに相手のロックした行を待つと、DBが片方を強制的に取り消します。
- [コネクションプールの枯渇](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/db-pool.html): DBとの接続数は決まっているため、遅いクエリが接続を占有すると、残りの要求は待たされます。
- [レプリケーション遅延](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/db-replica-lag.html): 書き込みはプライマリに、読み込みはレプリカから行う構成で、レプリカの追従が遅れると、書いたばかりの内容が見えません。
- [チェックポイント・ログフラッシュ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/db-checkpoint.html): DBがメモリ上の変更分を定期的にまとめてディスクに書き込む瞬間、クエリが遅くなります。
- [コールドキャッシュ（再起動直後）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/db-cold-cache.html): DBを再起動するとメモリ上のキャッシュが空になっているため、しばらくはすべての読み込みがディスクから行われます。
- [ログイン殺到とN+1クエリ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/db-login-storm.html): キャラクター1体を読み込むたびに数十回の個別クエリを発行していると、数万人の同時ログインは数百万件のクエリになります。
- [大規模なバッチ処理](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/db-batch.html): ランキング集計、郵便の一括送信、古いデータの整理をサービス中に実行すると、ロックとディスクを占有します。
- [DBのフェイルオーバー](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/db-failover.html): プライマリが落ちてスタンバイDBに切り替わる間は書き込みができず、レプリケーションが間に合わなかった最後のデータは失われることがあります。
- [長い保存間隔による進行状況の消失](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/db-save-interval.html): 負荷を減らすために数分に1回しか保存しないと、その間にサーバーが落ちた場合に進行状況が失われます。
- [キャッシュスタンピード](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/db-cache-stampede.html): 人気データのキャッシュが同時に期限切れになると、数千件の要求が一斉にDBへ殺到します。
- [長時間開いたままのトランザクション](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/db-long-tx.html): 1つのトランザクションが長く開いたままだと、ロックを持ち続けるうえ、DBが古いバージョンのデータを整理（purge）できないため、全体が徐々に遅くなります。
- [Redisの遅いコマンド](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/db-redis-block.html): Redisはコマンドを1つずつ順番に処理するため、遅いコマンドが1つあると、その後ろのすべての要求が止まります。
- [実行計画の変化によるクエリ遅延](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/db-plan-flip.html): コードは変わっていないのに、DBが同じクエリの処理方法（実行計画）を変えると、昨日2msだったクエリが今日は数百msになります。
- [サービス中のスキーマ変更（DDL）によるロック](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/db-ddl-lock.html): サービス中にテーブルへカラムやインデックスを追加すると、一瞬だけ必要なロック1つのために、そのテーブルを使うすべての要求が待たされることがあります。

## L13 サーバー構成と運用

- [ゲートウェイ・プロキシ経由](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/in-gateway.html): クライアントとゲームサーバーの間に中継サーバーを置くと、経由するたびに処理時間が加わり、そのサーバーが単一障害点になります。
- [ゾーン移動（サーバー間の引き継ぎ）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/in-zone-transfer.html): 別のエリアやダンジョンに入るとき、キャラクター情報を別のサーバーへ引き渡す過程で遅延や失敗が起きます。
- [カスケード障害](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/in-cascade.html): 1つのサービスが遅くなると、それを呼び出すサーバーが応答待ちで塞がり、関係のない機能まで止まります。
- [補助サーバーの障害](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/in-subservice.html): チャット・パーティ・オークションのように、ゲームサーバーとは別に動くサーバーで障害が起きると、その機能だけが動かなくなります。
- [デプロイ・再起動](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/in-deploy.html): アップデートのためにサーバーを再起動するとき、接続を移さずに止めると、そのサーバーにいた人は切断され、終了直前の保存と再接続が一気に集中します。
- [オートスケーリングの遅れ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/in-autoscale.html): 人が集中するとサーバーを自動で増やしますが、準備に数分かかり、その間は既存のサーバーが過負荷になります。
- [ログ・監視の過負荷](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/in-monitoring.html): 障害が起きるとログが急増し、ログを同期で送るサーバーはログのせいでさらに遅くなります。
- [サーバー間の時刻のずれ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/in-clock-skew.html): サーバーごとに時計が少しずつずれていると、クールタイム・バフ・イベント開始の判定がサーバーごとに食い違います。
- [大量のマクロ・ボット](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/in-bots.html): ボットは人よりはるかに頻繁にリクエストを送り、サーバーのスループットを食いつぶします。
- [外部サービスへの依存](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/in-external.html): プラットフォームのログイン、決済、本人確認などの外部サービスが遅くなったり止まったりすると、その段階で先に進めなくなります。
- [マッチメイキング・リージョン割り当ての誤り](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/in-region-match.html): 近いリージョンがあるのに遠いリージョンのサーバーに割り当てられると、回線に問題がなくても、そのユーザーだけPingが常に高くなります。
- [TLS証明書の期限切れ・設定ミス](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/in-cert.html): ログイン・API・アップデートサーバーの証明書が期限切れになったり中間証明書が抜けていたりすると、その瞬間から新たに接続するクライアントのTLS接続が失敗します。
- [ログイン待機列の上限・再接続猶予の不足](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/in-login-queue.html): リリース直後やメンテ明けに接続が集中すると、ログイン待機列が上限に達して新たな待機を拒否し、待っていたユーザーは一瞬切れた間に順番を失って最後尾に戻されます。

## 同期設計

- [サーバー応答後にだけ演出（リクエスト・レスポンス方式）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sy-request-response.html): ボタンを押しても、サーバーの応答が来るまでアニメーションも音も出ません。Pingがそのまま反応速度になります。
- [逐次往復の多いプロトコル（chatty）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sy-chatty.html): 1回の操作でサーバーとの往復が順番に何回も必要になると、Pingがその回数分だけ積み重なります。
- [スキルの先行入力なし](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sy-no-queue.html): 前のスキルがサーバーで終わったという確認を受けるまで次のスキルを押せないと、連携のたびに往復時間が挟まります。
- [Pingに削られる短い判定の受付時間](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sy-short-window.html): 回避・パリィ・ガードのように反応すべき時間が短いと、Pingがその時間を削ってしまい、よけられない攻撃が生まれます。
- [ラグコンペンセーションのない判定](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sy-no-lagcomp.html): サーバーが「今のサーバー上の位置」だけで命中を判定すると、自分が見た画面と判定が食い違います。
- [過剰なラグコンペンセーション](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sy-lagcomp-overreach.html): 攻撃者を基準に巻き戻しすぎると、撃たれる側はもう隠れたのに当たります。
- [クライアント権威型](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sy-client-auth.html): それぞれが自分の結果を決めると、自分の画面は快適ですが、ほかの人の画面と結果が食い違い、チートにも弱くなります。
- [ロックステップでの最も遅いプレイヤー待ち](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sy-lockstep.html): 全員が同じターンを一緒に計算する構造では、1人の入力が遅れると全員が待たされます。
- [ロールバックネットコードの予測失敗](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sy-rollback.html): 相手の入力を予測して先に見せ、外れたら巻き戻して計算し直します。Pingが大きいほど巻き戻す幅が大きくなります。
- [タイムスタンプなしの受信即時再生](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sy-no-timestamp.html): サーバーのイベントに発生時刻を付けず、受け取ったらすぐに再生すると、ネットワークのジッターがそのまま演出のタイミングのばらつきになります。
- [二重のティック待ち](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sy-double-tick.html): リクエストを次のティックまでためてから処理し、結果もその次のティックで送ると、ティック間隔が2回分加わります。
- [厳しすぎるサーバー検証](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sy-strict-check.html): 移動速度・クールタイム・射程をサーバーが厳しくチェックしすぎると、ジッターでまとめて届いた正常な入力まで拒否します。
- [ホスト（部屋主）型の構成](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sy-host.html): 1人のプレイヤーのPCがサーバーの役割をすると、その人の回線とPC性能が全員の体感を決めます。
- [先行演出後のサーバー拒否](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sy-optimistic-reject.html): 自分の画面で先に見せたヒット・スキルを後からサーバーが認めないと、確かに見た結果がなかったことになります。
- [コマンド同期の経路計算の不一致](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sy-path-mismatch.html): 「ここへ行け」だけをやり取りして経路は両側でそれぞれ計算すると、計算が少し違うだけで、キャラクターやモンスターが別の経路を進んだ後、元の位置に引き戻されます。
- [低いスナップショット送信レート](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/sy-low-send-rate.html): サーバーが位置の更新（スナップショット）を1秒に数回しか送らないと、その分だけ補間バッファを長く取る必要があり、ほかのキャラクターをより遠い過去の姿で見ることになります。

## 一部のユーザーだけに起きる問題

- [回線が重い人がほかの人の画面でまとめて動く](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-slow-burst.html): 回線が悪い人の入力は、不規則にまとまってサーバーに届きます。サーバーがティックごとに受け取った分だけ適用すると、ほかの人の目にはそのキャラクターが一瞬止まってから一気に何歩も進んで見えます。
- [受信即時処理のサーバーで起きる早送り](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-event-server.html): パケットが届くたびにすぐ処理して通知するサーバーでは、回線が重い人のまとまって届いた行動が立て続けに即実行されます。
- [プレイヤーごとの入力バッファのサイズ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-input-buffer.html): サーバーが人ごとに入力を少しためておき、1ティックに1つずつ取り出して使うと、ほかの人の目にはなめらかですが、本人の行動がサーバーで確定するタイミングはその分遅れます。
- [特定の通信事業者のユーザーに集中する検証の誤検知](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-isp-validation.html): ジッターが大きい回線を使う人は入力がまとまって届くため、サーバーの速度・クールタイムのチェックに頻繁に引っかかります。
- [回線が重いパーティメンバー1人とボスのギミック](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-raid-member.html): 全員が決まった瞬間に一緒に反応しなければならないレイドのギミックでは、回線が重い1人の遅れた反応がパーティ全体の失敗になります。
- [モンスターの制御権が遅いクライアントにある](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-mob-control.html): サーバー負荷を減らすため、モンスターの移動計算を近くのプレイヤー1人のクライアントに任せるゲームがあります。その人の回線が悪いと、そのモンスターが全員の画面でおかしな動きをします。
- [特定キャラクターのデータ肥大化](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-heavy-char.html): アイテム・郵便が数千個たまっていたり、フレンド・ブロックリストやバフが極端に多かったりするキャラクターは、接続時・保存時・周囲への通知で扱う量がほかの人の数倍になります。回線に関係なく、そのキャラクターでだけ重くなります。
- [チャンネル・インスタンス・フェーズの違い](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-phase.html): 2つのキャラクターが別のチャンネルやインスタンスにいたり、クエストの進行度によって見えるNPCが変わる別の「フェーズ」にいたりすると、互いに違う世界を見ることになります。
- [ロード中に届いた出現通知の破棄](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-loading-drop.html): ゾーンに入るとすぐにサーバーが周囲のNPCの出現通知を送りますが、クライアントがまだマップを読み込んでいる最中なので、その通知を破棄してしまいます。
- [視界登録の順序の乱れ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-aoi-race.html): キャラクターが視界グリッドに登録される瞬間と、NPCがグリッドのセルを移る瞬間が重なると、そのNPCの出現通知が漏れることがあります。
- [基準スナップショットの欠落](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-baseline.html): サーバーが「前回から変わったものだけ」を送る方式では、最初に1回送る全体の情報（基準）を失うと、その後の差分を適用できません。
- [消滅通知の欠落（ゴースト）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-ghost.html): 逆に「消えた」という通知を取りこぼすと、すでに死んだか去ったNPC・プレイヤーが自分の画面にだけ残ります。
- [入場直後に集中する出現情報の欠落](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-spawn-burst.html): ゾーンに入った瞬間、サーバーは周囲の数十〜数百個のオブジェクトの出現情報を一気に送ります。これを非信頼（unreliable）チャネルで送ったり、ロード中でソケットを読めない間に受信バッファがあふれたりすると、一部が消えて二度と届きません。
- [オブジェクトIDの再利用による混同](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-id-reuse.html): 倒されたNPCが再び出現するときにサーバーが同じオブジェクトIDを使い回すと、その間に消滅通知を取りこぼしたクライアントは、新しいNPCを古いNPCと誤認します。
- [固定UDPポートの衝突](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-port-collision.html): クライアントが決まったローカルポートを使うように作られていると、同じPCの2つ目のクライアントはそのポートを使えないか、1つ目とパケットを分け合って受け取ることになります。
- [IP・端末基準のセッション識別バグ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-session-key.html): サーバーや中継サーバーが接続をIPや端末IDで区別していると、同じPC（同じグローバルIP）の2つのクライアントを1人として認識します。
- [多重起動の制限](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-multiclient.html): セキュリティモジュールやサーバーのポリシーが1台のPCでの複数クライアントを制限していると、2つ目のクライアントは起動・接続ができないか、先に起動した側が切断されます。一部のゲームは追加のクライアントの機能だけを制限します。
- [バックグラウンドウィンドウの処理制限](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-background.html): バックグラウンドウィンドウのクライアントでは、ゲーム・エンジン・OSがフレームと処理を減らします。受け取ったパケットを時間内に処理できず、詰まったりあふれたりします。
- [キャッシュ・アセットファイルへの同時アクセスの競合](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-asset-lock.html): 2つのクライアントが同じキャッシュフォルダーに同時に書き込んだりファイルをロックしたりすると、片方がNPCのモデル・テクスチャを読み込めなくなります。
- [メモリ・VRAM不足によるストリーミングの失敗](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-vram.html): 2つのクライアントがビデオメモリを分け合うと、新たに必要なモデル・テクスチャを載せる場所がなく、一部が描画されません。
- [表示オプションの違い](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-display-option.html): 表示人数の制限、NPCのネームプレート・モデルの非表示、低スペックモードなどのオプションが2つのクライアントで違うと、見えるものが変わります。
- [クライアントのバージョン・データの不一致](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-version.html): 2つ目のクライアントが別のインストール版だったりアップデートが済んでいなかったりすると、サーバーが送った新しいNPCのIDを知らないため、黙って無視します。
- [接続ごとの送信バジェット・優先度](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-priority.html): サーバーが接続ごとに送る量に上限を設けて近いものから送ると、上限が低く設定された側は、遠くにいるNPCを遅れて受け取るか、受け取れません。
- [時刻推定の誤差によるオブジェクトの保留](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/pt-clock-hold.html): クライアントが推定したサーバー時刻がずれていると、届いたばかりのオブジェクト情報を「まだ未来」として保留したり、「古すぎる」として破棄したりします。

## TCP再送の根本原因

- [無線区間のパケットロス](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/rt-wireless.html): Wi-Fiとモバイル回線は、無線区間で何度か再送し、それでも届かなければパケットを破棄します。破棄されたパケットは、TCPがかなり後になってから送り直します。
- [ボトルネックでのキューあふれ（輻輳によるロス）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/rt-queue-drop.html): ルーター、通信事業者どうしの接続区間、データセンターの回線のように、最も細い箇所のキューが満杯になると、新しく届くパケットを破棄します。
- [送信バーストによる浅いバッファのあふれ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/rt-burst.html): サーバーがティックごとに数千人分の更新を一瞬でまとめて送ると、スイッチの小さなバッファやクラウドの瞬間的な上限が1ms足らずであふれ、一部が破棄されます。
- [ポリサーによる超過分の破棄](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/rt-policer.html): 通信事業者の料金プラン、クラウドインスタンスの上限、DDoS対策機器は、決められた速度を超えるパケットをキューに入れずにすぐ破棄することもあります。
- [物理エラー（不良ケーブル・光モジュール・コネクター）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/rt-physical.html): ケーブルの損傷、ほこりの付いた光コネクター、寿命を迎えた光モジュールはビットエラーを起こし、壊れたパケットは機器が黙って破棄します。
- [デュプレックスの不一致](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/rt-duplex.html): 片側はオートネゴシエーション、もう片側は速度・デュプレックスを固定にしておくと、片側が半二重で動作し、負荷がかかるたびに衝突（コリジョン）でパケットを失います。
- [受信サーバーのホストでのパケット破棄](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/rt-host-drop.html): パケットはサーバーまで届いたのに、NICのリングバッファ（到着したパケットを一時的に入れておくバッファ）があふれたり、カーネルで受信処理を担うコアが飽和したりして破棄されます。
- [ファイアウォール・接続追跡による破棄](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/rt-stateful-fw.html): ファイアウォールやLinuxの接続追跡（conntrack、通過する接続をテーブルに記録する機能）は、テーブルが満杯になったり、接続の状態が合わないと判断したりすると、パケットを破棄します。
- [中間機器の処理上限超過（ファイアウォール・IPS・DDoS対策）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/rt-appliance-pps.html): ファイアウォール、侵入防止システム（IPS）、DDoS対策機器は、通過するパケットを1つずつ検査します。検査能力を超えた瞬間から、処理しきれなかったパケットを破棄します。
- [MTUブラックホール（大きいパケットだけ繰り返し失われる）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/rt-mtu.html): 途中の区間が受け取れるサイズが小さくなったのに「大きすぎる」という通知（ICMP）が遮断されると、大きなパケットは何度送り直しても消え続けます。
- [接続中のNAT・ロードバランサーのマッピング期限切れ](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/rt-mapping.html): アイドル接続のマッピング（この接続をどこに転送するかを記録したエントリ）を中間機器が消すと、次に送るパケットは転送されません。再送だけを繰り返した末に切断されるか、機器が接続拒否（RST）を返してすぐに切断されます。
- [経路変更・ECMPの不良経路](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/rt-path.html): インターネットの経路が切り替わる数秒の間、または複数のECMP経路のうち不良な経路に割り当てられた接続で、パケットが消えます。
- [遅延の急上昇による不要な再送](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/rt-spurious-delay.html): パケットは消えておらず、一時的にとても遅れて届いただけなのに、その遅延がRTOより長いと、送信側はパケットロスと判断して再送します。
- [順序の入れ替わりによる不要な高速再送](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/rt-reorder.html): 複数の経路や束ねたリンクを通る間にパケットの順序が入れ替わると、受信側が重複ACKで「抜けたパケットがある」と知らせ、送信側は問題のないパケットを送り直します。
- [ACKの遅れ・消失（上り回線の飽和）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/rt-ack-path.html): データは問題なく届いているのに、「受け取った」というACKが満杯の上りキューで遅れたり消えたりすると、送信側はパケットロスと判断して再送します。
- [RTOの設定が環境に合っていない](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/rt-rto-setting.html): RTOの最小値を下げすぎると少し遅れただけで不要な再送が起き、デフォルト値（200ms）はゲームにとっては長すぎて、1回失うたびに長く止まります。
- [thin streamの遅い回復](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/rt-thin.html): ゲームのように小さなパケットをまばらに送ると、「後続のパケット3つ」がそろう前にRTOが先に来ます。大容量の転送と比べて、同じパケットロスでもはるかに長く止まります。
- [中間機器によるTCPオプションの除去](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/rt-sack-stripped.html): 一部のファイアウォール・高速化装置がTCPオプションを消したり書き換えたりすると、複数のパケットを失ったときに1往復に1つずつしか回復できなくなったり、ウィンドウ（一度に送れる量）が小さくなったりして遅くなります。
- [ゼロウィンドウ（再送のように見える停止）](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/rt-zero-window.html): 受信側のプログラムがソケットを読むのが間に合わず、バッファが満杯になると、送信側は送信を止めてゼロウィンドウプローブだけを送ります。回線の問題ではありません。
- [接続要求（SYN）の再送](https://jungrok5.github.io/mmo-lag-anatomy/ja/c/rt-syn.html): 接続要求が接続待ちキュー（backlog）のあふれやファイアウォールの遮断で消えると、クライアントOSは1秒後から間隔を延ばしながら送り直します。

## 切り分けと事例

- [観測データで切り分ける](https://jungrok5.github.io/mmo-lag-anatomy/ja/#judge): 範囲 → 時点 → 階層の切り分けの流れ、切り分けシグナル表、グラフの形13種類、数値の読み方（平均とp99）
- [状況別の手順](https://jungrok5.github.io/mmo-lag-anatomy/ja/text.html#playbooks): アップデート後のラグ、海外の国・地域の追加
- [実際の障害事例](https://jungrok5.github.io/mmo-lag-anatomy/ja/text.html#cases): 開発元・運営会社が公開したポストモーテムと関連する原因

## 他の言語

- [한국어 (Korean)](https://jungrok5.github.io/mmo-lag-anatomy/llms.txt)
- [English](https://jungrok5.github.io/mmo-lag-anatomy/en/llms.txt)
- [简体中文 (Chinese (Simplified))](https://jungrok5.github.io/mmo-lag-anatomy/zh-cn/llms.txt)
- [繁體中文 (Chinese (Traditional, Taiwan))](https://jungrok5.github.io/mmo-lag-anatomy/zh-tw/llms.txt)
- [Deutsch (German)](https://jungrok5.github.io/mmo-lag-anatomy/de/llms.txt)
- [ไทย (Thai)](https://jungrok5.github.io/mmo-lag-anatomy/th/llms.txt)
- [Tiếng Việt (Vietnamese)](https://jungrok5.github.io/mmo-lag-anatomy/vi/llms.txt)
- [Русский (Russian)](https://jungrok5.github.io/mmo-lag-anatomy/ru/llms.txt)
- [Português (Brasil) (Portuguese (Brazil))](https://jungrok5.github.io/mmo-lag-anatomy/pt-br/llms.txt)
- [Español (Spanish)](https://jungrok5.github.io/mmo-lag-anatomy/es/llms.txt)
- [Bahasa Indonesia (Indonesian)](https://jungrok5.github.io/mmo-lag-anatomy/id/llms.txt)

## Optional

- [GitHubリポジトリ](https://github.com/jungrok5/mmo-lag-anatomy): ソースコード、データ形式、コントリビュートの方法
- [作成者：Jeongrok Oh](https://jungrok5.github.io/resume/en/): 履歴書