Traceroute計測・監視
Tracerouteとは
Tracerouteとは、IPネットワークにおいて、ある端末から別の端末までの経路情報を取得するツールです。
コマンドとしては、Linuxであればtraceroute、Windowsであればtracertです。
Tracerouteによって、どのようなIPアドレスを経由して、どのくらいの速度で通信できているかを計測・監視することが可能です。
Tracerouteで、ネットワーク通信における重要な3つの情報を取得できます。
- レイテンシ
-
通信の起点となる端末から、相手先端末まで、パケットを送ったら戻ってくるまでの時間です。
インターネットの通信を高速道路に例えるならば、レイテンシは速度に該当します。
Webサイト、ストリーミング、Web会議、ゲームなど、現在のインターネット上の殆どのアプリケーションは、リアルタイム性が求められるため、このレイテンシの値が重要です。 - ホップ数
-
通信の起点となる端末から、相手先端末まで、どれだけのノード(ネットワーク機器やサーバ)を経由したか、その数です。
インターネットの通信を高速道路に例えるならば、ホップ数は料金所やインターチェンジに該当します。
ホップ数が少ない程に、より安定してより高速な通信が可能になります。
品質管理や統計学で「分散の加法性」と呼ばれる、ノード毎の通信のばらつき(分散)が足されていくのを小さくできるからです。 - パケットロス
-
通信の起点となる端末から、相手先端末まで、通信を行った場合にパケットが消失してしまった回数です。
インターネットの通信を高速道路に例えるならば、パケットロスは自動車の事故に該当します。
パケットが消失してしまった場合には、再度、送りなおす必要があり、その処理時間分、相手先端末でパケットからデータを組み立てるまでの時間が遅延することになります。
レイテンシとスループット:インターネット品質の真の指標
従来、日本では通信回線の品質を「下り1Gbps」のようなスループットで評価してきました。しかし、この指標は必ずしも実際のユーザー体験を反映していません。
スループットは大容量ファイルのダウンロードには重要ですが、日常的なWebブラウジング、ストリーミング、オンラインゲームなどでは、その高速性を十分に活用できません。
これらのアプリケーションでは、数Mbpsで十分な場合が多いのです。
さらに、高スループットが必ずしも良好な接続品質を意味するわけではありません。
レイテンシが大きかったり、パケットロスが発生していても、スループットは高い数値を示すことがあります。
これは、TCPプロトコルの再送メカニズムにより、データの整合性が保たれるためです。
一般的な速度測定サイト(例:fast.com)は、主にスループットを推定していますが、これは接続品質の一側面に過ぎません。
より包括的な評価には、Cloudflareの Speed Testのような、リアルタイムでスループットの変動を示すツールが有用です。
現代のインターネットサービスの品質管理においては、スループットよりも以下の指標がより重要です。
- レイテンシ:データの往復時間
- ホップ数:データが経由するネットワークノードの数
- パケットロス率:送信されたデータパケットの損失率
これらの指標を総合的に監視することで、より正確にユーザー体験を反映した接続品質の評価が可能になります。
結論として、高スループットは魅力的な数字ですが、実際のインターネット利用では、低レイテンシと安定した接続の方が重要です。
ユーザーと事業者の両方が、これらの指標に注目することで、より良いインターネット体験の実現につながるでしょう。
Traceroute計測・監視とは
Traceroute計測・監視は、日本道路交通情報センターの高速道路の混雑状況のニュースのように、各地から自社Webサイトまでのレイテンシ、ホップ数、パケットロスを計測・監視します。
CDNを使っている場合には、CDNが割り当てたEdge Serverまでのレイテンシ、ホップ数、パケットロスを計測・監視します。
サービスに遅延や接続障害が発生した際に、Tracerouteのデータがあると、下のレイヤーでの通信が確保できているかどうかの判断が可能となります。
また、Layer3のIP、Layer4のTCPやUDPでの遅延が生じている、パケットロスが発生している場合は、当然ながら、障害や遅延の際の対応策が変わります。
監視するサービスに合わせたプロトコル選択
Tracerouteは、Webサイトやアプリの性能の計測・監視の基本となるネットワークの接続性と性能を監視する上で重要な役割を果たします。
サービス、Webサイトやアプリで使っているプロトコルに合わせて、Tracerouteを実行する必要があります。
- HTTP/1.1: TCP
- HTTP/2: TCP
- HTTP/3: QUIC
- DNS: UDP
- WebRTC: UDP
Tracerouteのユースケース
Tracerouteは、ネットワーク品質管理のさまざまな場面で活用できます。
- 性能ボトルネックの検出
- 特定のホップでのレイテンシ急上昇や遅延を特定し、パフォーマンスが低下しているネットワークセグメントを切り分けます。
- 宛先への到達性検証
- 最終宛先に到達可能かどうかを確認し、到達できない場合はどのホップで障害が発生しているかを特定します。
- ネットワーク経路の可視化
- 送信元から宛先までの各ホップを特定し、ネットワーク経路の変化を検出します。経路変更はレイテンシ増加や接続不安定の原因となるため、定常的な監視が重要です。
- 地理的ルーティングの検証(Geo-Location Validation)
- パケットの物理的な経路をトレースし、地理的なルーティングの正確性を検証します。意図しない遠回りルーティング(トロンボーニング)や誤ルーティングの検出に有効です。
- Path MTU Discovery
- 経路上の最大伝送単位(MTU)を特定し、パケットフラグメンテーションを防止してパケット配送を最適化します。フラグメンテーションはレイテンシ増加やパケットロスの原因となります。
- DSCP検証
- 全ホップにわたってDSCPマーキングを検証し、QoS(Quality of Service)ポリシーが正しく遵守されているかを確認します。音声・映像など優先度の高いトラフィックの品質保証に不可欠です。
- MPLSパストレーシング
- MPLSのラベルスイッチドパスを明らかにし、通常のTracerouteでは見えない隠れたルーティング層を検出します。ISPや専用線環境での経路把握に有用です。
- ECNモニタリング
- 経路上でECN(Explicit Congestion Notification)ビットの状態を観測し、ネットワーク輻輳の早期兆候を検出します。輻輳が深刻化する前に対策を講じることが可能です。
- クラウドサービスの経路可視化
- AWS・Azure・GCP内のネットワークホップを識別・ラベリングし、クラウド特有の経路をトレースして、ルーティングの問題を切り分けます。マルチクラウド環境での障害対応に有効です。
Tracerouteで使うプロトコルと仕組み
SpeedDataのTraceroute計測・監視では、送信元からプローブを送出する際に、IPヘッダのTTL(Time to Live)値を1から順に増やしながらパケットを送信します。
各中継ホップはTTLを1減算し、TTLが0になるとパケットを破棄してICMPの「TTL expired」メッセージを送信元に返します。
パケットが最終宛先に到達した場合は、宛先から通常の応答、またはICMPのポート到達不能メッセージが返ります(UDP・QUIC・TCPでよく見られます)。
このTTLを1ずつ増やす仕組みにより、経路上の全ホップのIPアドレスとレイテンシを取得できます。
ICMP
ICMPを使ったTracerouteは、ICMPが主にエラー検出用であるため、経路上のエラーがないかどうかを検証する可用性の目的で使います。
ICMP Tracerouteの利点
- 広範な互換性
-
ICMPはインターネットプロトコルスタックの中核的な部分であるため、ほぼ全てのインターネット接続デバイスがICMPをサポートしています。
そのため、ICMP Tracerouteは広範囲のデバイスと互換性があります。 - 簡易性と普及度
-
ICMP Tracerouteは初期のTraceroute実装であり、その動作原理はよく理解されています。
多くのシステムとネットワーク管理者がICMP Tracerouteに親しみ、それを用いることでネットワーク経路の問題を迅速に特定できます。 - 経路追跡
-
ICMP Tracerouteは、パケットが経由するルーターのリストと、それぞれのルーターまでのラウンドトリップタイム(RTT)を提供します。
これにより、経路上のネットワーク遅延やパケットロスの発生源を特定できます。 - ネットワーク診断
- ICMP Tracerouteは、特定の宛先への経路に問題があるかどうかを確認するための強力なツールです。
ICMP Tracerouteの制限
ファイアウォールやネットワーク機器がICMPパケットをブロックまたはレート制限している環境では、トレース結果が不完全になる場合があります。
ICMPのみに頼ったTracerouteでは、経路上の全ホップを正確に把握できないケースがあるため、用途に応じてTCPやQUICでのTracerouteを併用することが推奨されます。
ICMP Tracerouteの活用シナリオ
- ネットワーク経路の初期診断および到達性の確認
- 一般的なサーバー・ネットワーク機器への疎通確認
- TCPやQUICでのTracerouteと組み合わせた経路の比較検証
TCP
TCPを使ったTracerouteは、ICMPをネットワーク機器でブロックしている場合に使うことが多かったです。
昨今ではHTTP/HTTPSなど、TCP上で稼働するプロトコルの基本性能を確認するために使うようになりました。
TCP Tracerouteは、宛先ポートとして80番を使用します(traceroute全体を通じて固定)。
各ホップへのプローブはTCP SYNパケットで送信し、送信元ポートはプローブごとにOSが動的に選択します。
TCP Tracerouteの利点
- ファイアウォールとの互換性
- 一部のファイアウォールやネットワークデバイスはICMPパケット(通常のTracerouteで使用される)をブロックまたは制限しますが、ほとんどのデバイスはTCPパケットを許可するため、TCP Tracerouteは経路上でブロックされる可能性が低いです。
- HTTP/TCPの実際のパスの確認
-
TCP Tracerouteは、HTTP/1.1やHTTP/2のようなTCPベースのプロトコルの通信が実際に経由する経路を確認するのに役立ちます。
これは特にTCPとUDPでルーティングが異なる可能性があるネットワーク環境で有用です。 - ポートレベルの診断
-
TCP Tracerouteを使用すると、特定のTCPポート(例えばHTTPの80番ポートやHTTPSの443番ポート)への経路を確認することができます。
これにより、特定のサービスに影響を与える可能性のあるネットワークの問題を特定できます。 - 経路上の問題の特定
-
TCP Tracerouteは、通信が失敗した場合や遅延がある場合など、TCP通信に問題が発生している原因を追跡するのに役立ちます。
パケットがどのルータを経由して、どこで遅延またはロスが発生しているかを確認することができます。
TCP Tracerouteの制限
TCP SYNパケットを使用するため、ロードバランサーが介在する環境では往路と復路でパケットの経路が異なる場合があります。
この場合、取得できる経路情報が実際の通信経路を正確に反映しないことがあります。より正確な経路把握にはTCP InSessionの使用を推奨します。
TCP Tracerouteの活用シナリオ
- HTTP/1.1・HTTP/2を使用するWebサイトの通信経路診断
- ICMPがブロックされた環境でのネットワーク経路調査
- 特定のTCPポート(80番・443番)への経路確認
TCP InSession
ネットワーク診断において、従来のTracerouteには重要な制限がありました。
セキュリティ対策としてICMPパケットがドロップされたり、ファイアウォールでブロックされることで、トレース結果が不完全になり、問題の特定が困難になることがありました。
TCP SYNパケットを使用したTracerouteも、ロードバランサーの存在により往復のパケット経路が異なる場合があり、正確な経路把握に課題がありました。
これらの課題に対応するため、SpeedDataのTraceroute計測・監視ではTCP InSession方式を採用しています。
SACK(Selective Acknowledgment)を効率的に利用する新アルゴリズムを採用した「Pietrasanta Traceroute」と名付けられたこの方式は、以下の特徴を持ちます。
- Traceroute 結果取得までの SACK 収集
- サイズ順の並べ替えとインターバル内容考慮によるプローブ割り当て
- GitHub でオープンソースとして公開
TCP InSession の動作
TCP InSession は、まず宛先との3ウェイハンドシェイクを完了してTCPセッションを確立してから、プローブを送信します。
プローブには従来のSYNパケットではなくTCPデータパケットを使用します。これにより、ファイアウォールやロードバランサーが介在する環境でも、実際のHTTP/1.1・HTTP/2通信が通過する経路を正確にトレースできます。
宛先ポートはtraceroute全体を通じて80番で固定され、送信元ポートはセッション開始時にOSが選択したポートが維持されます。
TCP InSessionが何らかの理由でTCPコネクションの確立に失敗した場合は、通常のTCP Tracerouteにフォールバックします。
この際、テスト結果(Recordsページ)にフォールバックした旨の警告メッセージが表示されます。
TCP InSession の主な利点
- 高いセキュリティ互換性
-
ファイアウォールやネットワークデバイスによるブロックを回避できます。
1デバイスあたり1つのACKのみを送信し、過剰なACK検出による制限を防ぎます。 - TCP ベースプロトコルの実経路確認
- HTTP/1.1 や HTTP/2 などの TCP ベースプロトコルが実際に通過する経路を正確に追跡します。
- 高速な診断処理
- 短時間で処理を完了し、「その瞬間」のネットワーク状況を適切に捉えます。
- 複雑なネットワーク環境での正確性
- ロードバランサーが介在する環境でも、正確な経路情報を追跡し、問題箇所を特定します。
TCP InSession の制限
TCPコネクションの確立(3ウェイハンドシェイク)が成功することが前提となるため、宛先ホストがTCP 80番ポートで応答しない場合は通常のTCP Tracerouteにフォールバックします。
フォールバック時はテスト結果に警告メッセージが表示されるため、結果の解釈に注意が必要です。
TCP InSession の活用シナリオ
- ロードバランサーが介在するWebサービスの実経路診断
- HTTP/1.1・HTTP/2サービスの本番通信経路の継続的な監視
- ファイアウォールやセキュリティ機器が多層に配置された企業ネットワークの診断
UDP
UDP Traceroute は、ゲームやストリーミング配信のようなUDPベースのプロトコルを使用するアプリケーションのネットワーク経路を調査するための重要なツールです。
このツールは、UDPデータパケットが通過するルーターとその遅延を可視化し、ネットワークの問題を特定するのに役立ちます。
UDPとTCPでは通過するネットワーク経路が異なる場合があるため、UDP Traceroute は UDP 特有の問題を診断する上で特に有用です。
宛先ポートは33434番から開始し、プローブごとに1ずつインクリメントします(90ポート後に33434に戻ります)。
ユーザーが特定のポートを指定した場合は、そのポートを起点にインクリメントし続けます。
送信元ポートはプローブごとにOSが動的に選択します。
UDP Traceroute の主な利点
- 広範な互換性
- IPとUDPに依存するため、ほとんどのシステムやネットワークデバイスでサポートされています。
- 詳細な経路トレース
- パケットが通過するルーターとその遅延を明確に表示します。
- 効果的なネットワーク診断
- 経路上の問題、遅延、パケットロスの発生箇所を特定します。
- UDPサービスの最適化
- ゲーム、VoIPやストリーミングなど、UDPベースのサービスのパフォーマンス問題を診断するのに特に有効です。
UDP Traceroute の制限
ファイアウォールやネットワーク設定によってUDPトラフィックがブロックまたはフィルタリングされている環境では、正確な経路情報を取得できない場合があります。
また、UDPはコネクションレス型プロトコルであるため、経路情報の取得はICMPのポート到達不能メッセージへの応答に依存します。
UDP Traceroute の活用シナリオ
- UDPベースのゲームサーバーの接続問題診断
- VoIPサービスの品質改善
- 動画ストリーミングサービスの配信経路分析
QUIC Traceroute
QUIC(Quick UDP Internet Connections)は、World Wide Web の運用でますます使用される現代的なプロトコルです。
UDPをベースとしながら、接続確立、輻輳制御、暗号化といった高度なメカニズムを提供します。
HTTP/3がQUICをトランスポート層として採用していることからも、その重要性が伺えます。
QUIC Traceroute は、この次世代プロトコルに特化したネットワーク診断ツールです。
プローブとしてQUICの初期ハンドシェイクフェーズで使用されるQUIC Initialパケットを送出し、各ホップの応答時間とルーティング経路を計測します。
宛先ポートはtraceroute全体を通じて443番で固定され、送信元ポートはプローブごとにOSが選択します。
これにより、HTTP/3ベースのアプリケーションの実際の通信経路を可視化し、パフォーマンスの最適化に役立ちます。
QUIC Tracerouteの主な利点
- QUICサポートの確認
- 宛先がQUICをサポートしているかどうかを検証します。ポート443でQUIC Initialハンドシェイクが成立すれば、QUICによる通信が可能な環境であることを確認できます。
- HTTP/3経路の実測
- HTTP/3が実際に使用するQUICの通信経路をトレースします。HTTP/1.1やHTTP/2(TCP)とは異なる経路をたどる場合があるため、HTTP/3サービスの品質管理には専用のQUIC Tracerouteが必要です。
- ネットワーク最適化
- QUIC特有の問題を診断し、パフォーマンスを向上させます。
QUIC Traceroute の制限
QUICはUDPベースであるため、UDPトラフィックをブロックするネットワーク環境ではQUIC Tracerouteが正常に動作しない場合があります。
また、QUIC Tracerouteはネットワーク経路の確認を目的としており、HTTP/3対応の有無はAlt-Svcレスポンスヘッダなど別途の方法で確認が必要です。
QUIC Traceroute の活用シナリオ
- HTTP/3 ウェブサイトの読み込み速度最適化
- QUICベースのストリーミングサービスの品質改善
- QUICを使用するモバイルアプリケーションの接続問題診断
- 新しいQUIC実装のテストと検証
- ネットワークインフラストラクチャのQUIC対応状況の評価
Traceroute + Ping
SpeedDataのTraceroute計測・監視では、通常の経路トレースと合わせて、宛先ホストへの追加Pingを実行します。
同一プロトコルで宛先に確実に到達するよう十分なTTL値(デフォルト128)を設定したプローブを宛先に対して20本送信します。プローブ間のデフォルト間隔は250msです。
この宛先へのPingから、Ping Round Trip・パケットロス・ジッターの3つのサマリーメトリクスが算出されます。詳細は計測メトリクスを参照してください。
Tracerouteの経路情報とPingのサマリーメトリクスを組み合わせることで、「どの経路を通っているか」と「その経路での通信品質がどうか」を一度に把握できます。
実装
ターゲットとなるホスト名、もしくはIPアドレスをご提供いただきます。
札幌、東京、大阪、福岡の国内4都市から、定常的にTracerouteを実行して、経路上のレイテンシとパケットロスを計測・監視します。
計測頻度で、パケットロスを検知する確率が変わります。
パケットロスの発生確率は、途中経路のネットワーク機器の品質や負荷に問題が無ければ、ポアソン分布に従います。
計測頻度は、1分、5分、15分からお選びいただきますが、1分が推奨です。
SpeedDataのTraceroute計測・監視は、Pietrasanta Tracerouteで稼働します。
詳細設定
基本的なTraceroute設定に加えて、以下の詳細設定が利用できます。詳細設定の活用シナリオについてはTracerouteのユースケースもあわせて参照してください。
- DSCP値の設定
-
TracerouteプローブのIPヘッダにDSCP(Differentiated Services Code Point)値を設定します。
QoSポリシーが正しく適用されているかを確認する際に使用します。音声・映像など優先度の高いトラフィッククラスを模倣してトレースすることで、優先制御が経路全体で維持されているかを検証できます。 - Path MTU Discoveryの有効化
-
送信元から宛先までの経路上における最大伝送単位(MTU)を発見します。
経路MTUよりも大きなパケットを送信するとフラグメンテーションが発生し、レイテンシ増加やパケットロスの原因となります。事前にMTUを把握しておくことで、これを防ぐことが可能です。 - ECNの有効化
-
TracerouteプローブのIPヘッダ(および使用プロトコルがTCPの場合はTCPヘッダ)にECN(Explicit Congestion Notification)値を設定します。
経路上でECNビットがどのように扱われているかを観測することで、ネットワーク輻輳の早期兆候を検出し、パケットドロップが発生する前に対処できます。 - 最大失敗ホップ数の増加
-
Traceroute実行中に許容する連続失敗ホップの最大数を設定します。デフォルトは10で、最大20まで増加可能です。
一部のネットワーク機器がICMPを返さない環境でも、より多くの経路情報を取得できます。EnterpriseノードおよびCloudノードのみ対応しています。 - Ping回数の増加
-
TTLあたりに送信するプローブ数を設定します。デフォルトは3で、最大20まで増加可能です。
プローブ数を増やすことで、断続的なパケットロスの検出精度が向上します。EnterpriseノードおよびCloudノードのみ対応しています。
データ
計測メトリクス
SpeedDataのTraceroute計測・監視では、以下のメトリクスを取得できます。
Ping Round Trip・パケットロス・ジッターの3項目は、Traceroute + Pingの宛先への追加Pingプローブから算出されます。
- Ping Round Trip(ms)
- 宛先へのPingプローブの平均往復時間です。経路上の個々のホップではなく、最終宛先との実際の通信品質を反映します。Tracerouteのテストサマリーにおける主要な応答時間指標となります。
- ジッター(ms)
- ネットワーク上のパケット伝送レイテンシの分散の尺度です。値が大きいほどレイテンシが不安定であることを示し、VoIPや動画ストリーミング、オンラインゲームの品質劣化につながります。
- パケットロス(%)
- 送信したPingプローブのうち応答が得られなかった割合です。(受信パケット数 ÷ 送信パケット数)× 100で算出されます。
- ホップ数(# Hops)
- 送信元から宛先までの経路上の総ホップ数です。
- AS数(# ASs)
- テスト中に経由した自律システム(Autonomous System)の総数です。
- 都市数(# Cities)
- テスト中に経由した都市の総数です。
- 国数(# Countries)
- テスト中に経由した国の総数です。
- Apdex
-
多様なアプリケーションのパフォーマンス指標を「ユーザー満足度」に変換するスコアリング機構です。
設定した応答時間の閾値をもとに、Satisfied(満足)・Tolerating(許容)・Frustrated(不満)の3段階で評価します。
詳細は Apdex Alliance を参照してください。 - Experience Score
- ユーザーの総合的な体験を0〜100のスコアで表す複合指標です。
散布図
累積分布関数
個票の詳細データ
長所・短所
長所
- 指定の都市・ISP・キャリアでのTracerouteを定常的に行うことで、遅延や通信障害などを素早く検知して対応することが可能です。
- ICMP・TCP・TCP InSession・UDP・QUICの5プロトコルから、監視対象のサービスが実際に使用するプロトコルに合わせて選択できるため、実際の通信経路を正確に把握できます。
- TCP InSessionを使用することで、ロードバランサーやファイアウォールが介在する複雑なネットワーク環境でも、実際のHTTP/1.1・HTTP/2通信が通過する経路を正確にトレースできます。
- DSCP検証・Path MTU Discovery・ECNモニタリングなどの詳細設定により、QoSポリシーの遵守確認やネットワーク輻輳の早期検知など、高度なネットワーク品質管理が可能です。
- Traceroute + Pingにより、経路情報(どの経路を通っているか)と通信品質(レイテンシ・パケットロス・ジッター)を一度に計測できます。
短所
- 指定した都市・ISP・キャリア以外のデータは取得できないので、計測していない地域については「暗黒状態」となります。
- ICMPをブロックするネットワーク環境では、ICMP Tracerouteのトレース結果が不完全になる場合があります。用途に応じてTCPやQUICでのTracerouteを併用してください。
- UDPおよびQUICのTracerouteは、ファイアウォールでUDPトラフィックがブロックされている環境では正常に動作しない場合があります。
アラート/レポート機能
アラート機能
- エラー検知
- パケットロスを検知した場合には、即座に、指定のメールアドレスにアラートメールを送信することが可能です。
- 遅延検知
- レイテンシの閾値を設定し、その値を超えた観測値を計測した場合には、即座に指定のアドレスにアラートメールを送信することが可能です。
レポート機能
日次で、Tracerouteのレイテンシについて、グラフ化したレポートを指定のメールアドレスに送信することが可能です。