パケットロスに専用のテストが必要な理由
インターネットで送信するデータはすべて、小さなパケットに分割されます。その一部が失われても、TCPベースのアプリは欠けた部分を再要求するだけなので、Webページは表示され、ダウンロードも完了します。しかし、ゲームやボイスチャット、ビデオ通話は待つことができないため、次のパケットへ進んでしまいます。その結果、相手がワープしたり、言葉が途切れたり、映像が固まったりします。パケットロステストは、通常の速度テストでは見えない問題を可視化します。
測定の仕組み
このテストでは、ブラウザと選択したテストサーバーとの間にWebRTCデータチャネルを確立します。チャネルは順序保証なし・再送ゼロ（maxRetransmits: 0）に設定されているため、失われたパケットが再送されることはありません。これは多くのゲームやVoIPアプリが使用するUDPの動作に非常に近いものです。接続はサーバー自身のTURNサービスを経由して中継されるため、厳しいNAT環境や多くの企業ネットワークでも動作します。
各パケットにはシーケンス番号が付いています。サーバーはパケットを受け取るとすぐに送り返し、テスト終了時に受信したIDの一覧を返します。ブラウザはその一覧を、送信したパケットおよび戻ってきたパケットと照合します。
- サーバーに届かなかったパケットは上りロスとして数えます。
- サーバーには届いたものの戻ってこなかったパケットは下りロスとして数えます。
- 戻ってきたものの、役に立たないほど遅れたパケットは遅延として記録します。
- 順序の乱れたパケットと重複パケットは、それぞれ別のカウンターで集計します。
適切な設定の選び方
パケットサイズ、頻度、時間によって、テストがどのような通信を再現するかが決まります。初期設定はほとんどの方に適していますが、特定の問題を調べたい場合は次のプロファイルを試してください。
- ゲーム：64～128バイト、毎秒60～100パケット、1～2分。
- 音声通話：160～200バイト、毎秒50パケット、1分。
- 大きなパケット：1000～1200バイト、毎秒20～50パケット。
- 長時間の監視：低頻度、5分。
大きなパケットではロスが増え、小さなパケットでは増えない場合は、MTUの設定や回線の容量制限を確認してください。短いテストでは問題がないのに、長いテストでときどきまとまったロスが発生する場合は、Wi-Fiの電波干渉、ルーターの過熱、夜間の混雑などによる断続的な問題の可能性があります。
方向別のロスからわかること
パケットがどちらの方向で失われているかを知ることは、誰が問題を解決すべきかを見極める最も早い方法です。Wi-Fiの電波が弱い、クラウドバックアップが上り帯域を使い切っているなど、自宅内の問題は通常、上りロスとして現れます。下りロスは、プロバイダのネットワークの混雑、DSLやケーブル回線の品質、サーバーまでの経路上の混雑した中継点を示していることが多くあります。両方向でロスが見られる場合は、まずデバイスとルーター間の接続を、次にルーターと外部回線との接続を確認してください。
ジッター、MOS、接続評価
パケットロスだけで判断してはいけません。ジッター（連続する往復時間の差の絶対値の平均）は、遅延がどれだけ不安定かを示します。ジッターが高いとアプリはバッファリングを余儀なくされ、バッファの再生が終わった後に届いたパケットは事実上失われたのと同じになります。MOSスコアは、ITU-T G.107 Eモデルの簡易版を用いて遅延、ジッター、ロスを組み合わせ、音声通話がどのように聞こえるかを推定したものです。4以上なら良好、3.5未満なら明らかに品質が低下しています。A～Fの評価と安定性（%）は、これらすべてをひとつの概要にまとめたものです。
原因を絞り込む
- 同じデバイスで、Wi-Fiでテストした後に有線でテストします。大きな差がある場合、原因は無線ネットワークです。
- 別のサーバー拠点で繰り返します。特定のサーバーでのみロスが発生する場合、問題はその経路にあります。
- 朝と夜にそれぞれテストします。混雑時間帯にのみロスが発生する場合は、ネットワークの容量不足が考えられます。
- 必要に応じて、結果をCSVまたはJSONでダウンロードし、サポートへの問い合わせに添付してください。
手早く全体を確認するにはトップページのPingテストをご利用ください。特定のゲームがカクつく場合は、Valorant Pingテストなどのページでリージョンごとの遅延を比較してください。