パケットロステスト
ゲームや通話と同じ実際のUDPパケットでパケットロスをテストし、ロスが上り（アップロード）と下り（ダウンロード）のどちらで起きているかを確認できます。1回の測定で、遅延テスト、ジッターテスト、バッファブロートテストも同時に行えます。
最寄りのCloudflareデータセンター経由でUDPパケット3,000個を往復 · 1分 · 何も保存しません
到着したすべてのパケット例：光回線で1分間
- 時間どおり 2,995
- 遅延到着 0
- ロス 4
- 順序逆転 1
- 重複 0
このパケットロステストの仕組みは？
ブラウザーが小さなUDPパケットを一定の間隔で最寄りのCloudflareデータセンターへ送ってそのまま自分自身に戻し、戻ってこなかったパケットをすべて数えます。
パケットは、失われたメッセージを決して再送しない設定のWebRTCデータチャネルで送られます。そのため、消えたパケットは消えたままです。再送によって遅延として隠されることのない、実際のパケットロスです。中継はCloudflareのTURNサービスが担います。TURNはエニーキャストなので、ブラウザーは最寄りのCloudflare拠点に届き、リレーもそこに置かれます。ストリームの両端がブラウザー内にあり、1つの時計で計るため、各パケットの遅延は0.1ミリ秒単位で正確です。
このループのパケットは上りと下りで回線を2回通るため、それだけではどこでロスしたかがわかりません。そこで、短い音声通話を並行して行います。ブラウザーが無音の音声ストリームをCloudflareの通話サーバー（Realtime SFU）に送り、それを受け取り返します。Cloudflareが受信できなかったパケットを報告し、それが上りのロスです。その後に失われた分が下りのロスです。
負荷時の測定では、パケットを送り続けながら、Cloudflareのスピードテストサーバーとの間で下り、続いて上りの通信によって回線を満たします。回線が混雑したときに、ロス、ジッター、遅延がどう変わるかがわかります。
- ループ：全パケットの遅延と結果
- 通話：ロスした方向
- ロスしたパケット
判定ロス、バースト、負荷時の遅延の増加を、Microsoft Teamsの目標値またはCloudflareのゲーム向けスコアに照らして判定します。すべてのパケット1列が1秒、1つの印が1パケットです。時間どおり、遅延到着、ロス、順序逆転を示し、バーストは括弧でまとめます。上りか下りかテスト通話でロスを分けます。Cloudflareがあなたから受け取れなかった分と、あなたに戻る途中で失われた分です。スコアと評価動画配信、ゲーム、ビデオ通話向けのCloudflareのスコアと、WaveformによるA+〜Fのバッファブロート評価です。パケットロスとは何ですか？
パケットロスとは、端末から送り出されたデータパケットのうち、相手に届かなかったもの、または届いても遅すぎて使えなかったものの割合です。
ゲームや音声・ビデオ通話は、小さなパケットをUDPで毎秒何度も送り、失われたパケットの再送を待ちません。ロスしたパケットは、映像のフリーズ、通話の言葉の途切れ、キャラクターが元の位置に戻る現象になって表れます。ダウンロードやWebページはTCPを使い、失われた分を再送するため、ロスはページの表示が遅くなる形でしか表れません。通常のスピードテストでパケットロスがわからないのもこのためです。
このテストでは4つを数えます。ロス：3秒経っても届かないパケット。IETFのロス指標で報告が求められている待ち時間です。遅延到着：届いたものの、ほかより大きく遅れたパケット。順序逆転：後から送ったパケットより遅く届いたもの（RFC 4737）。重複：2回届き、1回としてカウントしたものです。
- 時間どおりほかのパケットと一緒に到着
- 遅延到着到着したが、ほかより大きく遅れた：通話には間に合わない
- ロス3秒以内に戻らなかった
- 順序逆転後から送ったパケットより遅く到着
- 重複2回到着し、1回としてカウント
パケットロスはどのくらいまで許容できますか？
ビデオ通話なら1%未満です。MicrosoftのTeams向け目標は、どの15秒間でもロス1%未満、どの200ミリ秒間でも10%未満で、Zoomは2%以下を推奨しています。
このページの各判定は、公開された1つのルールにそのまま従っています。ビデオ通話：端末からネットワークエッジまでの経路についてのMicrosoft Teamsの目標値（往復100 ms未満、どの15秒間でもロス1%未満、どの200 ms間でもバーストロス10%未満、ジッター30 ms未満、順序逆転0.05%未満）と、Zoomの推奨値（遅延150 ms、ジッター40 ms、ロス2%）です。
ゲームと動画配信：speed.cloudflare.comと同じポイントを使う、Cloudflareのネットワーク品質スコアです。ロス1%未満で満点、1%〜5%で半分、5%〜25%で0点、それを超えるとポイントが差し引かれます。ゲームについては、ゲームメーカーが公開しているロスの上限はありません。毎秒64回や128回の更新では、バースト状の1%でも目に見えるカクつきになります。
- 1%未満：満点、Teamsの目標内
- 1%〜2%：Zoomの推奨内
- 2%超：両方の範囲外
パケットロスはランダムか、バーストか？
割合と同じくらいパターンが重要です。分散した2%のロスは通話ではほとんど気づきませんが、数回のバーストで失われた2%は、音声が何度も途切れる原因になります。
このテストでは、パケットが連続して失われた区間（RFC 6534）をロスの発生として数えて最長のものを示し、ITU-T G.107のバースト比を算出します。ロスがランダムなら1、集中していれば1を超えます。バーストの原因は通常、ルーターやモデムのキューがいっぱいになって同じストリームの複数のパケットを一度に破棄すること、またはWi-Fiの一時的な途切れです。
短いテストでは、ロスがないことを証明できません。750パケット中ロスが0でも、ロス率は0.4%未満のどこかにあり得るため、このページでは単なる0%ではなく範囲を表示します。断続的に起きるロスを捉えるには、3分間のテストを実行してください。
ランダム単発のロスが散在
- ロス発生回数
- 60
- 最長バースト
- 1 · 20 ms
- バースト比
- 0.98
通話では：ときどき小さなノイズ
バースト12個連続が5回
- ロス発生回数
- 5
- 最長バースト
- 12 · 240 ms
- バースト比
- 11.76
通話では：1分間に240 msの途切れが5回
ジッターとは？どのように測定しますか？
ジッターとは、パケットごとの遅延の変動の大きさです。通話やゲームはパケットをバッファーに溜めて変動をならしますが、そのバッファーが遅延を増やします。
このページは、WebRTCの通話アプリが表示するのと同じRFC 3550の計算式でジッターを測定します。到着するパケット間の遅延の変化を、直近のパケットで平滑化したものです。ほかのツールは別の式を使います。Cloudflareのスピードテストは連続するPingの差の平均、WaveformとOoklaは平均値からの偏差を使うため、ジッターの値をそのまま比較することはできません。このページのCloudflareのスコアには、当然ながらCloudflare自身の計算式を使っています。
転送時間（ms）。変化のたびにJは差の16分の1だけ動くため、1回のスパイクではわずかに上がるだけで、安定したパケットが続くと下がっていきます。
バッファブロートとは？負荷時の遅延
バッファブロートとは、回線が混雑したときに加わる余分な遅延です。ルーターやモデムがデータを溜め込みすぎるため、すべてのパケットがダウンロードやアップロードの後ろで順番待ちになります。
負荷時の測定では、アイドル時、下り通信中、上り通信中の順に遅延を測り、その増加をWaveformの基準で評価します。増加が5 ms未満ならA+、30未満でA、60未満でB、200未満でC、400未満でD、400 ms以上でFです。平均遅延と、2方向のうち悪いほうから算出します。
解決策は、ルーターのスマートキュー管理（SQM）です。CAKEまたはFQ-CoDelを使い、速度を回線の実速度より少し低く設定します。OpenWrtのガイドでは、測定した速度の約90%です。その後もう一度テストすると、評価がAまたはA+に上がるはずです。
Waveform- A+<5
- A<30
- B<60
- C<200
- D<400
- F400+
パケットロスの原因と直し方は？
パケットロスの多くは、Wi-Fi、混雑した回線（バッファブロート）、不良なケーブルやポート、プロバイダーのネットワークが原因です。テストのパターンから、どれが原因かがわかります。
下り・上りの通信中にだけロスがあるならバッファブロートです。SQMをオンにしてください。Wi-Fiでアイドル時にランダムなロスがあるなら、電波干渉か距離が原因です。有線でもう一度テストしてください。有線でもロスがある場合は、ケーブルの損傷、ポートの不良、ルーターの古いファームウェアが考えられます。有線でSQMもオンなのに、通話テストでロスが下り側にあるなら、問題はたいていルーターの先にあります。テストの共有リンクとCSVをプロバイダーに送ってください。
見られるパターンを選択
下り・上りの通信中にだけロス
考えられる原因
バッファブロート：ルーターやモデムのキューがあふれている
対処法
SQM（CAKEまたはFQ-CoDel）を回線速度の約90%でオンにする
Wi-Fiのときだけ、単発のロスがランダムに発生
考えられる原因
電波干渉、距離、または弱い電波
対処法
ルーターに近づく、5 GHzに切り替える、または有線にする
有線でも、アイドル時でもロス
考えられる原因
ケーブルやポートの不良、古いファームウェア
対処法
ケーブルとポートを替え、ルーターを更新する
有線でSQMもオンなのに下り側でロス
考えられる原因
プロバイダーのネットワーク
対処法
共有リンクとCSVをプロバイダーに送る
パケットロステスト、Pingテスト、スピードテストの違い
スピードテストは回線が運べるデータ量、Pingテストは1往復にかかる時間、パケットロステストは小さなパケットがどれだけ確実に届くかを測ります。それぞれ別の問いに答えるものです。
世界各地への遅延を見るにはPingテスト、通話が途切れたりゲームがカクついたりするときはこのパケットロステスト、ダウンロードが遅いときはスピードテストを使ってください。
| 比較 | パケットロステスト | Pingテスト | スピードテスト |
|---|---|---|---|
| 測定するもの | ロス、遅延到着、順序逆転したパケット、ジッター、負荷時の遅延 | サーバーやリージョンまでの往復時間 | 下り・上りのスループット |
| プロトコル | UDP（再送なし） | ICMP、TCP、HTTPS | TCP（再送でロスが隠れる） |
| わかること | 通話が途切れ、ゲームがカクつく理由 | サーバーまでの体感的な距離 | ダウンロードが遅い理由 |