ゲームラグ白書 › 症状から探す
早送り:原因36件と担当
別名:一気に動く、早回し、まとめて処理
図のあるメインページの症状辞典で開く →
止まっていた画面が動き出すと同時に、たまっていた動き・ヒット・ダメージが一気に早回しで流れます。
モンスターやプレイヤーが早送りのように動き、ダメージの数字とエフェクトが一度にどっと出ます。
どこかでたまっていたパケットが、一度に解放されました。TCPの再送待ち、サーバーの追いつき処理、クライアントの処理遅れが代表的です。
この症状を引き起こす原因
L1 クライアントのゲームプロセス
L2 クライアントのOS・端末
- バックグラウンドプロセスによるCPU占有: ウイルス対策ソフトのスキャン、Windows Update、配信ソフト、ブラウザの動画がコアを占有すると、ゲームスレッドがCPUを割り当ててもらえずに待たされます。 (外部・外部)
- 受信バッファのあふれ: ゲームの処理が忙しく、ソケット(OSが提供するネットワーク送受信のインターフェース)からパケットを取り出すのが遅れると、OSのバッファがあふれます。 (ゲーム開発チーム・クライアント開発)
- 同じ端末の他のアプリによる帯域幅の占有: クラウド同期、大容量のダウンロード、ゲームのアップデートが同じPCで動いていると、ゲームのパケットがキューで待たされます。 (外部・外部)
- ウィンドウの最小化・非アクティブ時の処理制限: ほかのウィンドウを見たりゲームを最小化したりすると、ゲームとWindowsが電力を節約するためにゲームの処理を遅くします。戻ると遅れていたパケットが押し寄せるか、すでに切断されています。 (ゲーム開発チーム・クライアント開発)
L3 家庭内ネットワーク
- バッファブロート(ルーターのキュー): 家族の誰かが動画をアップロードしたり大きなファイルをダウンロードしたりすると、ルーターのキューに数百ms分のパケットがたまり、ゲームのパケットもその後ろで待たされます。 (外部・外部)
L6 サーバーのネットワークカード
- クラウドホストのメンテナンス・ライブマイグレーション: クラウド事業者は物理サーバー(ホスト)をメンテナンスするとき、仮想マシンを別のホストに移したり(ライブマイグレーション)、一時的に止めたりします。その間はサーバー全体が止まり、止まる時間が長いと接続が切れます。 (インフラチーム・サーバーインフラ)
L7 サーバーOS(カーネル)
- カーネルのソケットバッファ不足: 送受信バッファが小さいと、バーストトラフィックが集中したときに、UDPで受信したパケットは破棄され、TCPの送信はバッファに空きがなくブロックされます。 (インフラチーム・サーバーインフラ)
- システム時刻のジャンプ(NTPステップ): サーバーの時刻が一度に数秒前後に調整されると、システム時刻に依存するタイマーが一斉に発火したり止まったりします。 (ゲーム開発チーム・サーバー開発)
L8 ソケットとプロトコル
- TCPのHOLブロッキング: TCPは順序を守るため、失われたパケットを1つ受け取り直すまで、後から届いたパケットをゲームに渡しません。 (ゲーム開発チーム・サーバー開発)
- 信頼性UDPの再送設定: UDPの上に独自に作った再送ルールが保守的すぎると復旧が遅れ、攻撃的すぎると回線をさらに詰まらせます。 (ゲーム開発チーム・サーバー開発)
- 輻輳制御による送信量の急減: TCPはパケットロスを輻輳のシグナルとみなし、送信速度を30〜50%落とします。Wi-Fiでのパケットロスにも同じように反応します。 (インフラチーム・サーバーインフラ)
L9 サーバーのゲームプロセス
- ブロードキャストの急増: 1人の動きを、その人が見えている全員に送ると、集まった人数の2乗に比例する数の更新を送ることになります。 (ゲーム開発チーム・サーバー開発)
- 1体に集中する戦闘(ワールドボス): 数百人が1体のボスを同時に攻撃すると、そのボス1体の計算が1か所に集中し、ヒット情報が見ている全員に送信されます。 (ゲーム開発チーム・サーバー開発)
- 密集エリア進入時のスポーン集中: 人でいっぱいの街にテレポートすると、サーバーは新たに見えるようになった数百人の外見・装備・状態を一度に送らなければなりません。 (ゲーム開発チーム・サーバー開発)
L10 メモリ
- サーバーGCの全停止: Java・C#のサーバーがガベージを回収するために全スレッドを止めている間(stop-the-world)、サーバー全体が止まります。 (ゲーム開発チーム・サーバー開発)
同期設計
- タイムスタンプなしの受信即時再生: サーバーのイベントに発生時刻を付けず、受け取ったらすぐに再生すると、ネットワークのジッターがそのまま演出のタイミングのばらつきになります。 (ゲーム開発チーム・クライアント開発)
一部のユーザーだけに起きる問題
- 回線が重い人がほかの人の画面でまとめて動く: 回線が悪い人の入力は、不規則にまとまってサーバーに届きます。サーバーがティックごとに受け取った分だけ適用すると、ほかの人の目にはそのキャラクターが一瞬止まってから一気に何歩も進んで見えます。 (ゲーム開発チーム・サーバー開発)
- 受信即時処理のサーバーで起きる早送り: パケットが届くたびにすぐ処理して通知するサーバーでは、回線が重い人のまとまって届いた行動が立て続けに即実行されます。 (ゲーム開発チーム・サーバー開発)
- モンスターの制御権が遅いクライアントにある: サーバー負荷を減らすため、モンスターの移動計算を近くのプレイヤー1人のクライアントに任せるゲームがあります。その人の回線が悪いと、そのモンスターが全員の画面でおかしな動きをします。 (ゲーム開発チーム・サーバー開発)
- バックグラウンドウィンドウの処理制限: バックグラウンドウィンドウのクライアントでは、ゲーム・エンジン・OSがフレームと処理を減らします。受け取ったパケットを時間内に処理できず、詰まったりあふれたりします。 (ゲーム開発チーム・クライアント開発)
TCP再送の根本原因
- 無線区間のパケットロス: Wi-Fiとモバイル回線は、無線区間で何度か再送し、それでも届かなければパケットを破棄します。破棄されたパケットは、TCPがかなり後になってから送り直します。 (外部・外部)
- ボトルネックでのキューあふれ(輻輳によるロス): ルーター、通信事業者どうしの接続区間、データセンターの回線のように、最も細い箇所のキューが満杯になると、新しく届くパケットを破棄します。 (インフラチーム・ネットワークインフラ)
- 送信バーストによる浅いバッファのあふれ: サーバーがティックごとに数千人分の更新を一瞬でまとめて送ると、スイッチの小さなバッファやクラウドの瞬間的な上限が1ms足らずであふれ、一部が破棄されます。 (ゲーム開発チーム・サーバー開発)
- ポリサーによる超過分の破棄: 通信事業者の料金プラン、クラウドインスタンスの上限、DDoS対策機器は、決められた速度を超えるパケットをキューに入れずにすぐ破棄することもあります。 (インフラチーム・ネットワークインフラ)
- 物理エラー(不良ケーブル・光モジュール・コネクター): ケーブルの損傷、ほこりの付いた光コネクター、寿命を迎えた光モジュールはビットエラーを起こし、壊れたパケットは機器が黙って破棄します。 (インフラチーム・ネットワークインフラ)
- デュプレックスの不一致: 片側はオートネゴシエーション、もう片側は速度・デュプレックスを固定にしておくと、片側が半二重で動作し、負荷がかかるたびに衝突(コリジョン)でパケットを失います。 (インフラチーム・ネットワークインフラ)
- 受信サーバーのホストでのパケット破棄: パケットはサーバーまで届いたのに、NICのリングバッファ(到着したパケットを一時的に入れておくバッファ)があふれたり、カーネルで受信処理を担うコアが飽和したりして破棄されます。 (インフラチーム・サーバーインフラ)
- 中間機器の処理上限超過(ファイアウォール・IPS・DDoS対策): ファイアウォール、侵入防止システム(IPS)、DDoS対策機器は、通過するパケットを1つずつ検査します。検査能力を超えた瞬間から、処理しきれなかったパケットを破棄します。 (インフラチーム・ネットワークインフラ)
- 経路変更・ECMPの不良経路: インターネットの経路が切り替わる数秒の間、または複数のECMP経路のうち不良な経路に割り当てられた接続で、パケットが消えます。 (インフラチーム・ネットワークインフラ)
- 遅延の急上昇による不要な再送: パケットは消えておらず、一時的にとても遅れて届いただけなのに、その遅延がRTOより長いと、送信側はパケットロスと判断して再送します。 (外部・外部)
- RTOの設定が環境に合っていない: RTOの最小値を下げすぎると少し遅れただけで不要な再送が起き、デフォルト値(200ms)はゲームにとっては長すぎて、1回失うたびに長く止まります。 (インフラチーム・サーバーインフラ)
- thin streamの遅い回復: ゲームのように小さなパケットをまばらに送ると、「後続のパケット3つ」がそろう前にRTOが先に来ます。大容量の転送と比べて、同じパケットロスでもはるかに長く止まります。 (ゲーム開発チーム・サーバー開発)
- 中間機器によるTCPオプションの除去: 一部のファイアウォール・高速化装置がTCPオプションを消したり書き換えたりすると、複数のパケットを失ったときに1往復に1つずつしか回復できなくなったり、ウィンドウ(一度に送れる量)が小さくなったりして遅くなります。 (インフラチーム・ネットワークインフラ)
- ゼロウィンドウ(再送のように見える停止): 受信側のプログラムがソケットを読むのが間に合わず、バッファが満杯になると、送信側は送信を止めてゼロウィンドウプローブだけを送ります。回線の問題ではありません。 (ゲーム開発チーム・クライアント開発)
図のあるメインページの症状辞典を見る