
News Observation Lab for Future
Traceroute の仕組みと実際の動作

インターネットは一本の線ではない
ウェブサイトにアクセスすると瞬時に完了したように感じますが、実際にはリクエストは自宅ルータ、ISP の機器、地域交換点、場合によっては複数のプロバイダーのネットワークといった多数のルータを経由します。また、応答は同じ経路を逆走するとは限らず、途中の各デバイスは所有者が異なるため、自身についての情報を提供しません。そのため、ページ読み込みの遅延は見えないチェーン上のどこか一つのポイントで発生している可能性があります。
問題の概要
速度テストや ping が正常でも、途中のどこかで遅延やパケットロスが起こることがあります。ユーザーは「インターネット全体が故障している」のではなく、具体的にどのホップが遅延を引き起こしているかを知りたいと考えます。
主要用語の定義
- パケット:データは連続したストリームではなく、小さな単位(パケット)に分割され、ヘッダーに送信元と宛先が記載されています。
- ルータ/ホップ:パケットを受け取り、目的地へ一歩近づけて転送する装置。各ルータが「ホップ」と呼ばれ、通常の通信では 10〜20 ホップ程度になります。
- IP アドレス:ネットワーク上の機器を識別する番号で、住所のようなものです。
- TTL(Time To Live):パケットに設定された小さなカウンタで、ループ防止の役割を持ち、通過したホップ数を減算します。
- ICMP:ルータがエラーを報告するために使用する補助プロトコルで、診断情報を運びます。
- RTT(Round‑Trip Time):パケットが目的地まで到達し、返信が戻ってくるまでの時間で、ping や traceroute が測定します。
- UDP / TCP:データ搬送方式。TCP は信頼性が高く接続指向、UDP は高速だが保証なし。traceroute はこれらまたは直接 ICMP を使用します。
- ファイアウォール:規則に基づきトラフィックをフィルタリングし、traceroute が依存する診断メッセージをブロックすることがあります。
TTL を利用した経路探索の仕組み
各ルータはパケットを転送するときに TTL を 1 減らします。TTL が 0 になるとそのルータはパケットを破棄し、自身の IP アドレスから ICMP 「Time Exceeded」メッセージを返します。この挙動を利用して、traceroute は次のように経路を特定します。
- TTL=1 のパケットを送信 → 最初のルータが破棄し、応答で第 1 ホップが判明。
- TTL=2 のパケットを送信 → 第 1 ホップを通過し、第 2 ホップで破棄、応答で第 2 ホップが判明。
- この手順を繰り返し、TTL を増やしながら目的地に到達するまで続けます。
つまり、ルータに「あなたは誰?」と尋ねるのではなく、意図的にパケットを段階的に失わせ、その「死亡証明書」(ICMP 応答)の送信元アドレスからホップを推測しています。
トレースルートが送信するパケットの内容
各ホップで必要となる要素は次の通りです。
- 送信用プローブ:Unix 系では UDP パケット(未使用ポート)、Windows の tracert では ICMP エコー要求、ファイアウォール回避のために TCP SYN を使用することもあります。
- 生ソケット:TTL フィールドを書き換え、ICMP 応答を取得するために管理者権限が必要です。
- タイマー:プローブ送信時に開始し、応答受信時に停止してホップごとの RTT を算出します。
多くの実装はノイズ低減のために同一 TTL につき 3 回のプローブを送ります。また、ICMP 応答には元のパケットヘッダーが埋め込まれており、複数の TTL が同時に飛んでいても正しく対応付けられます。
教科書通りにならないケース
- ICMP がブロックまたはレート制限されると、応答が得られず「* * *」と表示されますが、これはルータが存在しないことを意味しません。
- MPLS ネットワークでは複数の物理ルータが 1 つのホップとして隠蔽され、実際の経路が簡略化されます。
- 非対称ルーティングにより、ICMP の帰路が往路と異なることがあり、測定された RTT は往復時間の合計となります。
- ロードバランシングにより同一 TTL のプローブが異なるリンクへ振り分けられ、同じホップが複数の IP アドレスとして現れることがあります。
- ICMP が優先的に処理されないルータは、負荷が高いときに応答が遅れたり欠落したりし、実際の障害と誤認されやすいです。
リアルタイムツールへの応用
従来の CLI traceroute はすべてのホップをバッチで取得し、最後に結果を表示します。リアルタイム性を求める場合は、次の設計が有効です。
- バックエンドが逐次的にホップ情報を生成し、クライアントへストリーム配信。
- フロントエンドは「未解決」「タイムアウト」「解決済み」などの状態を区別しながら、経路が伸びるたびに可視化。
- ICMP の取得には管理者権限が必要なため、ブラウザ側ではなくサーバー側でプローブを実行し、WebSocket 等の永続接続で結果を送信。
理解すべき理由
traceroute の出力はシンプルな番号付き IP と時間だけに見えますが、裏側ではエラーメッセージという副作用を利用した手法であり、ネットワークは意図的にマッピングを阻害しています。したがって、出力を文字通り信用せず、上記の制限や例外を踏まえて解釈することが重要です。
元記事: https://dev.to/sospeter/how-traceroute-actually-works-4od7