ネットワーク遅延を測定する方法：開発者の実践ガイド

ネットワークのレイテンシを測定したいですか？pingやtracerouteのようなシンプルで組み込みのコマンドラインツールを使って、往復時間 (RTT)を素早く把握することから始めることができます。または、ブラウザの開発者ツールを開いて、遅延がユーザーの実際の体験にどのように影響しているかを確認することもできます。

これらの方法は、データパケットがソースから目的地に移動し、再び戻るのにかかる時間を素早く把握するのに役立ちます。

レイテンシ測定が不可欠な理由

「どうやって測定するか」に入る前に、「なぜ測定するのか」について話しましょう。開発者やネットワークエンジニアにとって、レイテンシは単なる画面上の数字ではなく、ユーザー体験全体を形作る見えない手です。今日のアプリケーションでは、ミリ秒がすべてです。わずかな遅延でも、瞬時に感じられるサービスと壊れたサービスの違いになることがあります。

現実世界の影響を考えてみてください：

APIの応答性：単一の遅いAPIコールはドミノ効果を引き起こし、ユーザーのプロフィールの読み込みから重要な支払いの処理まで、すべてを遅らせる可能性があります。
リアルタイムデータストリーム：オンラインゲーム、ライブビデオ、または金融取引において、低く一貫したレイテンシは絶対的な基盤です。これがなければ、これらのアプリケーションは単に機能しません。
ユーザー維持：遅い読み込みのウェブサイトやアプリと高いバウンス率や放棄されたショッピングカートとの間には直接的な関係があります。これは、ビジネスに大きな影響を与えます。

主要なレイテンシ概念の区別

ネットワークのレイテンシを正確に測定するには、何を見ているのかを理解する必要があります。最も基本的な2つの概念は往復時間 (RTT)と片道レイテンシです。

RTTは、信号がポイントAからポイントBに移動し、再び戻るのにかかる総時間です。これは測定が簡単で、接続の一方の端にアクセスするだけで済むため、最も一般的に見られる指標です。

片道レイテンシは、その名の通り、データが単一の方向に移動するのにかかる時間を測定します。これは、両端で完全に同期した時計が必要なため、正確に測定するのが難しいですが、アップロードとダウンロードの経路が非常に異なる非対称接続に対しては、はるかに正確な指標です。

これらの重要性は、真剣な負荷パフォーマンステストを行うときに明確になります。ここでは理論が現実と交わり、ボトルネックが明らかになります。

数値を示すと、ネットワーク監視の専門家は一般的にレイテンシを次のように分類します：

低レイテンシ： 50ミリ秒未満
中程度のレイテンシ： 50-150 ms
高レイテンシ： 150 ms以上

私の経験では、近くのサーバーへの簡単なテストでは、完全に許容できる20-40 msが表示されることがあります。しかし、その数字は海を越えるトラフィックの場合、簡単に200 msを超えることがあり、これはアプリケーションのパフォーマンスにとって大きな影響を与える可能性があります。

出会う用語を理解するための簡単なリファレンスを以下に示します。

主要なレイテンシ概念の概要

概念	測定内容	重要性
レイテンシ (Ping)	単一のデータパケットがソースから目的地に移動し、再び戻るのにかかる時間。ミリ秒 (ms) で測定。	これは遅延の生の測定値です。低レイテンシは、ゲーム、VoIP、ビデオ会議などのリアルタイムアプリケーションにとって重要です。
往復時間 (RTT)	基本的にはレイテンシと同じで、信号を送信するのにかかる時間と確認応答を受け取るのにかかる時間の合計です。	RTTは、単一のポイントからレイテンシを測定する最も一般的で実用的な方法であり、`ping`のようなツールの標準的な指標です。
片道レイテンシ	パケットがソースから目的地に単一の方向に移動するのにかかる時間。	特にアップロードとダウンロードの経路に異なるレイテンシがある非対称ネットワークにおいて、より詳細な視点を提供します。
ジッター	時間の経過に伴うレイテンシの変動。パケット到着時間の不一致を測定します。	高いジッターは、ストリーミングメディアやオンライン通話において高いレイテンシと同様に悪影響を及ぼし、スタッタリング、バッファリング、グリッチを引き起こします。
帯域幅	特定の時間内にネットワーク接続を介して送信できるデータの最大量。MbpsまたはGbpsで測定。	しばしば速度と混同されますが、帯域幅は容量に関するものです。高い帯域幅を持っていても、高いレイテンシに悩まされることがあります。

これらの概念は、ネットワークパフォーマンスの問題を理解するための基礎となります。

ミリ秒を測定するストップウォッチがスマートフォンとノートパソコンに接続され、ネットワークレイテンシを示しています。

ここで、アクセス可能で統合されたツールが非常に重要になります。複雑な診断スイートを実行する代わりに、現代のブラウザ拡張機能や開発ツールは、ワークフローを離れることなく必要な洞察を提供できます。レイテンシ測定を、優れたソフトウェアの構築と維持の一部として、手間いらずのルーチンにすることが重要です。

コマンドラインレイテンシツールを使って実践する

ネットワークのパフォーマンスを本当に感じるためには、ターミナルを開く必要があります。コマンドラインは、接続に関する生の未加工データを提供する基本的なツールが見つかる場所です。これは、あなたと目的地の間を移動するパケットで本当に何が起こっているのかを見ることに関するものであり、レイテンシを測定することに真剣な開発者にとっての重要な第一歩です。

定番のユーティリティはpingです。非常にシンプルで、サーバーに小さなデータパケット（ICMPエコーリクエスト）を送信し、戻ってくるのを待つだけです。そのシンプルな往復が往復時間 (RTT)を計算する基礎となり、接続の健康状態を瞬時にチェックできます。

Pingを使った最初のレイテンシチェック

pingテストを実行するのは非常に簡単です。ターミナルまたはコマンドプロンプトを起動し、pingと入力し、テストしたいドメインを続けて入力します。

デフォルトでは、pingはmacOSとLinuxでは永遠に続き、Windowsでは4つのパケットを送信して停止します。実際の分析を行うには、これを制御する必要があります。10または20のパケットを送信することで、数個のパケットよりも接続の安定性をより信頼できる形で把握できます。

テストが完了すると、重要な数値を含むきれいな要約が表示されます：

送信/受信パケット：これにより、途中でデータが失われたかどうかがわかります。少量のパケット損失でも、ネットワークの問題に対する大きな警告信号です。
往復時間の最小/平均/最大/平均偏差: これらはあなたのコアレイテンシ統計です。最良のケース時間（min）、平均（avg）、最悪のケース（max）が得られます。mdev（平均偏差）は、ジッターの測定値であり、レイテンシがパケットごとにどれだけ変動するかを示します。

最小と最大のRTTの間のギャップに注意を払ってください。これが広い場合、接続は不安定であり、平均が良好に見えてもそうです。このジッターは、常に少し遅い接続よりも、ビデオ通話やゲームなどのリアルタイムアプリに対してはるかに破壊的です。

一般的な間違いは、平均RTTをちらっと見ることです。50msの平均は問題ないように見えるかもしれませんが、最小が20msで最大が250msの場合、ユーザー体験はカクカクして信頼性が低く感じられます。ジッターを理解するためには、常に全範囲を確認してください。

トレースルートとMTRでの追跡

では、pingが高いレイテンシやパケットロスを示した場合、何をすべきでしょうか？次の仕事は、問題がどこにあるのかを特定することです。それがtraceroute（Windowsではtracert）の役割です。これは、パケットが通過する全経路をマッピングし、あなたのマシンと最終目的地の間のすべての「ホップ」—各ルーター—を示します。

tracerouteの出力の各行はホップであり、通常、その時点までの3つの異なるレイテンシ測定値を示します。これにより、経路上の特定のルーターが大幅な遅延を引き起こしているのか、パケットをドロップしているのかを特定できます。

しかし、tracerouteは一度きりのスナップショットです。より動的で継続的な視点を得るために、私が知っているほとんどのネットワーク専門家はMTR（My Traceroute）を推奨しています。MTRは、pingとtracerouteを組み合わせた強化ツールのようなものです。経路上のすべてのホップにパケットを常に送信し、各ポイントでのレイテンシとパケットロスのライブで更新されるビューを提供します。これにより、単一のtracerouteでは見逃しがちな間欠的な問題を捉えるのに非常に効果的です。

ツールの選択が重要な理由

実際、数値がどれほど異なるかは驚くべきことです。Google Cloudによる詳細な実験では、標準のpingテストが平均RTT146マイクロ秒を報告しました。しかし、トランザクションを間髪入れずに送信する別のツールを使用したところ、RTTはわずか66.59マイクロ秒に低下しました—これは2倍以上の速さです！

これは、pingが時々レイテンシを過大評価する理由の完璧な例です。ツールがどのように機能するかを理解することが、信頼できる測定値を得るために重要であることを示しています。

iperfで接続の最高速度を測定する

レイテンシは常に全体像ではありません。時には、接続が実際にどれだけのデータを送信できるか—その帯域幅を知る必要があります。そのためのツールがiperfです。

pingが遅延を測定するのに対し、iperfはスループットに焦点を当てています。クライアント-サーバー接続を設定し、設定した時間内にできるだけ多くのデータを送信します。

iperfを使用するには、2台のマシンが必要です：

1台のマシンで、iperfをサーバーモードで実行します。接続を待機します。
もう1台のマシンで、iperfをクライアントモードで実行し、サーバーのアドレスを指定します。

クライアントが接続し、テストが開始されます。出力には、転送された総データ量と、最も重要なことに、メガビットまたはギガビット毎秒でのビットレート（帯域幅）が表示されます。これは、ネットワークリンクをストレステストし、その真の能力を見つけるための完璧な方法です。

ユーザーの視点からレイテンシを測定する

コマンドラインツールがネットワークの生の、フィルタリングされていない視点を提供する一方で、ウェブアプリケーションにとって本当に重要なのは、エンドユーザーが実際に体験するレイテンシです。ここで、ターミナルからブラウザ自体に焦点を移します。ブラウザ内で何が起こるかは、パフォーマンスに関するより豊かで関連性のあるストーリーを語ります。

単一のパケットの往復だけではありません。ユーザーが感じるレイテンシは、DNSルックアップ、TCPハンドシェイク、TLS交渉、サーバー処理時間、そしてもちろん、画面上にコンテンツを実際にレンダリングするのにかかる時間の複雑なカクテルです。幸いなことに、現代のブラウザにはこの全プロセスを解剖するための強力な組み込みツールが搭載されています。

ブラウザ開発者ツールの活用

主要なブラウザ—Chrome、Firefox、Edge、Safari—はすべて、開発者ツールのスイートを備えています。これらのツール内の「ネットワーク」タブは、サイトの読み込みを理解するためのコマンドセンターです。これは、ページをレンダリングするためにブラウザが行うすべてのリクエストの視覚的な内訳であるウォーターフォールチャートにすべてを表示します。

このウォーターフォールビューは非常に貴重です。初期のHTMLドキュメントやCSSスタイルシートから画像やAPI呼び出しまで、各アセットのダウンロードにかかった正確な時間を確認できます。さらに重要なのは、各リクエストのライフサイクルを明確なフェーズに分解することです：

DNSルックアップ: ドメイン名をIPアドレスに解決するのにかかる時間。
初期接続: サーバーとのTCP接続を確立するのにかかる時間。
SSL/TLSハンドシェイク: セキュアな接続を設定するために必要なオーバーヘッド。
最初のバイトまでの時間（TTFB）: これは非常に重要です。サーバーからの最初のバイトのデータを受信するまでにブラウザが待機した時間を測定します。
コンテンツダウンロード: リソース自体を実際にダウンロードするのにかかる時間。

たとえば、高いTTFBは、遅いバックエンドやサーバー側の処理問題の古典的な兆候です—これは単純なpingテストでは決して明らかになりません。このウォーターフォールを分析することで、どのリソースがレンダリングをブロックしているのか、または読み込みに時間がかかりすぎているのかを迅速に特定できます。

私の経験からの重要な教訓は、総読み込み時間だけでなく、ウォーターフォール内の最も長いバーを探すことです。単一の最適化されていない画像や遅いサードパーティAPIが、ページ全体を人質に取り、サイトの残りが非常に速くても悪いユーザー体験を生み出す可能性があります。

タイミングAPIを使用したプログラムによる測定

より自動化され、正確な測定を行うために、ブラウザの組み込みJavaScript APIを利用できます。ナビゲーションタイミングAPIとリソースタイミングAPIは、開発者ツールで見るのと同じ詳細なパフォーマンスデータにプログラム的にアクセスすることを可能にします。これは、実際の訪問者がサイトをどのように利用しているかを理解するためのリアルユーザーモニタリング（RUM）データを収集するのに最適です。

これらのメトリクスは、ブラウザコンソール内で数行のJavaScriptを使って取得できます。たとえば、メインページの読み込みに関するコアパフォーマンスタイミングを取得するには、performance.getEntriesByType('navigation')を使用します。これにより、貴重なタイムスタンプが詰まったオブジェクトが返されます。

そのデータから、重要なメトリクスを計算できます：

DNSルックアップ時間: domainLookupEnd - domainLookupStart
TCPハンドシェイク時間: connectEnd - connectStart
最初のバイトまでの時間（TTFB）: responseStart - requestStart
総ページ読み込み時間: loadEventEnd - startTime

記録を取らないと、後で結果を振り返ることができません。テストの結果や設定をすべて文書化しておきましょう。

これらのステップに従うことで、信頼性の高いデータを収集し、実際に役立つ洞察を得ることができます。

テストの「理由」を6ヶ月後に忘れてしまうでしょう。シンプルなログを保持してください：日付、時間、エンドポイント、使用したツール、観察したことの簡単なメモ。

体系的に行動することで、単にレイテンシを測定するだけでなく、それを真に理解することができます。この思慮深いアプローチが、ランダムな数字と信頼できるパフォーマンス指標を分けるものです。

数字の意味を理解する（避けるべきこと）

信号のピークを拡大鏡で示すグラフ、Wi-FiとEthernetのアイコンの隣に。

さて、テストを実行し、データの山ができました。ここからが本当の作業の始まりです—その生の数字を実際に意味のあるものに変換することです。データはあなたのネットワークの健康についての物語を語っています。あなたはそれを読む方法を学ぶ必要があります。

例えば、tracerouteでの往復時間（RTT）の突然のスパイクは、古典的な手がかりです。ホップ番号3でレイテンシが急上昇し、最後まで高いままであれば、問題を見つけた可能性があります：それは3番目のルーターか、その後のリンクです。しかし注意が必要です。もしその単一のホップだけが高いレイテンシを示し、最終目的地がまだ速い場合、それはあなたのテストが使用するトラフィックの種類を優先度を下げるように設定されたルーターかもしれません。これは一般的な誤警報で、あなたを迷わせることがあります。

ジッターとパケットロスの解読

単純なRTTを超えて見ることで、最も重要な洞察が得られます。高いジッターは、一貫性のないレイテンシのための洗練された言葉であり、一貫して高いレイテンシよりもはるかに破壊的です。これは特にリアルタイムのものに当てはまります。

結果が40msの平均RTTを示しているが、最小が10ms、最大が150msであれば、接続は不安定です。その大きな変動が、ビデオ通話での煩わしいスタッターやオンラインゲームでの怒りを引き起こすラグスパイクの原因です。

パケットロスはさらに大きな警告信号です。たとえ1%のパケットロスでも、TCPベースのアプリケーションを完全に麻痺させ、データを常に再送信させ、すべてを遅くします。テスト結果を見たとき、送信されたパケットと受信されたパケットの間に実際の違いがあれば、すぐに調査する必要があります。

私が見る最大の間違いの一つは、単一のテストが全体の物語を語ると仮定することです。ネットワークの状態は常に変化しています。午前3時に実行されたテストは、午後3時のピークビジネス時間のテストとはまったく異なります。真のパフォーマンスベースラインを得る唯一の方法は、一貫した繰り返しテストです。

問題を先取りするために、ネットワークパフォーマンスモニタリングの専用ツールを調べる価値があります。これにより、壊れたときに慌てて修正するのではなく、ネットワークを健康に保つための積極的なアプローチにシフトします。

最も一般的な測定ミス

世界最高のツールを使用しても、いくつかの単純なミスが結果を完全に無駄にすることがあります。信頼できるデータを得たいのであれば、これらの一般的な落とし穴を避けることは譲れません。

Wi-Fiでのテスト：本当に、やめておきましょう。無線接続は非常に不安定で、電子レンジから隣人のルーターまで、あらゆるものからの干渉を受けやすいです。真剣なレイテンシテストには、Ethernetケーブルで接続してください。これが安定した信頼できるベースラインを得る唯一の方法です。
VPNのオーバーヘッドを忘れる：VPNはセキュリティに優れていますが、トラフィックの旅に追加の停止と暗号化を加えます。これは常にレイテンシを増加させます。ユーザーの遅い接続を診断しようとしている場合、最初の質問の一つは「VPNを使用していますか？」であるべきです。VPNありとなしでテストすることで、どれだけの遅延が追加されているかを正確に示すことができます。
ローカルネットワークの混雑を無視する：他の誰かが帯域幅を独占している場合、テスト結果は歪むでしょう。もし同僚が4Kビデオをストリーミングしたり、大きなファイルをダウンロードしている間にテストを行っていると、レイテンシの数値は膨らみ、存在しない問題を追いかけることになります。

もう一つの微妙ですが重要な要素は、選択するツールです。異なるユーティリティが異なる方法でレイテンシを測定することを考慮すると、比較に使用するツールは常に一貫性を持たせ、各ツールが実際に何を測定しているのかを理解することが重要です—単純なICMPエコーか、複雑なアプリケーションレベルのリクエストか。パフォーマンスは多くのレイヤーに影響される可能性があることを忘れないでください。たとえば、ウェブパフォーマンスを掘り下げる場合、Cookie Editor Chrome Extensionに関するガイドが、クライアントサイドの要素がどのように役割を果たすかを示すことができます。

結果を正しい文脈で解釈し、これらの一般的なミスを避けることで、単に数字を収集するだけでなくなります。ネットワークのパフォーマンスの理由を理解し始め、それがより速く、より信頼性の高いシステムを構築する鍵となります。

ネットワークレイテンシに関する一般的な質問

適切なツールがあっても、ネットワークレイテンシを掘り下げ始めると、いくつかの一般的な質問が常に浮かび上がります。結果を理解するために、私がよく聞く最も頻繁な質問をいくつか見ていきましょう。

実際に「良い」レイテンシの数値とは？

これは古典的な「それは依存する」質問ですが、確かにいくつかの確固たるベンチマークを設定できます。「良い」レイテンシは、あなたが達成しようとしていることに完全に依存しています。

カジュアルなウェブブラウジング：私たちのほとんどにとって、100ms未満のRTTは完全に問題ありません。ページはすぐに読み込まれ、実際のラグを感じることはありません。
競技的なオンラインゲーム：ここでは、ミリ秒が重要です。真剣なゲーマーや高頻度取引者は、20msを大きく下回るレイテンシを求めています。それが勝敗を分けるのです。
ビデオ通話＆VoIP：ここでは、一貫性が重要です。150ms未満の安定したレイテンシと低いジッター（30ms未満）が必要で、そうでないと、途切れ途切れで同期が取れない感覚や、最悪の場合、通話が切れることになります。

一般的な指針として、私が知っているほとんどのネットワークの専門家は、50ms未満のものを低レイテンシと分類します。50-150msは中程度で、150msを超えると、ほとんどのインタラクティブなアプリケーションで遅れを感じ始めます。

なぜ私のPingとブラウザのスピードテストの結果は決して一致しないのか？

これは素晴らしい質問で、非常に一般的な混乱のポイントです。これは、コマンドラインのpingとブラウザベースのスピードテストが根本的に異なるツールであり、異なるものを測定しているために起こります。

まず、ほぼ確実に異なるサーバーに接続しています。ドメインをpingすると、特定のターゲットにヒットします。一方、ウェブスピードテストは、最良の結果を得るために、自身のネットワークから地理的に近いサーバーを見つけるように設計されています。

プロトコルも完全に異なります。PingはICMPという非常に軽量なプロトコルを使用します。ほとんどのブラウザテストはTCPを介して実行され、接続を確立するために全体のセットアッププロセス（「三者間ハンドシェイク」）が必要です。その初期のやり取りが、実際のテストが始まる前に少し時間を追加します。

最後に、ブラウザテストは純粋なネットワーク移動時間以上のものを含むことがよくあります。彼らの「レイテンシ」数値には、サーバー処理時間やブラウザ内の小さな遅延が含まれることがあり、これが生のICMP pingと比較して最終的な数値を膨らませることがあります。

実際にネットワークレイテンシを下げるにはどうすればよいですか？

レイテンシを減らすことは、オフィス内であれインターネット上であれ、ボトルネックを見つけて排除することに関するものです。

最初に見るべき場所は、あなたの周囲の環境です。最も効果的な変更は、Wi-Fiから有線のイーサネット接続に切り替えることです。これは安定性と速度においてゲームチェンジャーです。Wi-Fiを使用しなければならない場合は、ルーターに近づき、可能であれば5GHz帯に接続してください。通常、こちらの方が混雑していません。

ローカルネットワークを超えて見ると、時にはDNSの変更が役立つことがあります。より速いDNSサーバーを使用することで、ウェブサイトを調べる際の初期接続時間からミリ秒を削減できます。

あなたが管理するサービスへのアクセスを改善しようとしている場合、コンテンツ配信ネットワーク（CDN）が答えです。これは、あなたのコンテンツのコピーをユーザーに物理的に近い場所に配置することで機能します。また、VPNを使用している場合は、オフにしてみてください。その追加のホップと暗号化層は、ほぼ常にレイテンシを追加します。

企業のVPNが往復時間に70msもの遅延を追加するのを見たことがあります。素晴らしい接続が苛立たしいほど遅いものに変わることがあります。常にVPNの有無でテストして、実際にどの程度のパフォーマンスの影響を受けているかを確認してください。

レイテンシと帯域幅の本当の違いは何ですか？

これを正しく理解することは、ネットワークパフォーマンスを理解するための基本です。混同しやすいですが、これらは非常に異なる二つのものを測定しています。

私がいつも使うアナロジーは、ハイウェイのように考えることです。

帯域幅は、ハイウェイにいくつの車線があるかです。車線が多いほど、同時に移動できる車（データ）が増えます。
レイテンシは制限速度です。これは、単一の車（データパケット）がAからBに到達する速さを決定します。

巨大な10車線のハイウェイ（巨大な帯域幅）があり、制限速度が20 mph（高いレイテンシ）である場合、最終的には大量のデータを移動できますが、ビデオ通話のようなリアルタイムのものは非常に遅くなります。一方で、非常に低いレイテンシの接続は、帯域幅が大きくなくても非常にスナッピーで応答性が高く感じられます。素晴らしい体験のためには、両方の良いバランスが本当に必要です。

パフォーマンステストを日常のワークフローのシームレスな一部にする準備はできましたか？ShiftShift Extensionsスイートは、強力なスピードテスト、JSONフォーマッター、その他の開発者ツールをブラウザ内に直接配置し、単一のコマンドでアクセス可能にします。タブを juggling するのをやめて、よりスマートに作業を始めましょう。 ShiftShift Extensionsを無料でダウンロードして、今日から生産性を向上させましょう。