tracerouteがpingよりもはるかに長いのはなぜですか？
これを説明するには？
C:\Documents and Settings\Administrator>tracert google.com
Tracing route to google.com [64.233.189.104]
over a maximum of 30 Hops:
1 <1 ms <1 ms <1 ms 192.168.0.1
2 7 ms <1 ms <1 ms reserve.cableplus.com.cn [218.242.223.209]
3 108 ms 135 ms 163 ms 211.154.70.10
4 * * * Request timed out.
5 2 ms * 1 ms 211.154.64.114
6 1 ms 1 ms 1 ms 211.154.72.185
7 1 ms 1 ms 1 ms 202.96.222.77
8 2 ms 1 ms 2 ms 61.152.81.145
9 1 ms 2 ms 1 ms 61.152.86.54
10 1 ms 1 ms 1 ms 202.97.33.238
11 2 ms 2 ms 2 ms 202.97.33.54
12 2 ms 1 ms 2 ms 202.97.33.5
13 33 ms 33 ms 33 ms 202.97.61.50
14 34 ms 34 ms 34 ms 202.97.62.214
15 34 ms 186 ms 37 ms 209.85.241.56
16 35 ms 35 ms 44 ms 66.249.94.34
17 34 ms 34 ms 34 ms hkg01s01-in-f104.1e100.net [64.233.189.104]
Trace complete.
したがって、平均時間は：1 + 7 + 108 + 2 + 1 + 1 + 2 + 1 + 1 + 2 + 2 + 33 + 34 + 34 + 35 + 34 + 34 + 35 + 34である必要があります。これは、 ping
C:\Documents and Settings\Administrator>ping google.com
Pinging google.com [64.233.189.104] with 32 bytes of data:
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Ping statistics for 64.233.189.104:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 34ms, Maximum = 34ms, Average = 34ms
これらの数値をすべて加算することはできません。これは、googleへのパス上の各ホップへのping時間です。したがって、本来、パスの各区間はどんどん遠ざかり、pingの時間はさまざまです。 tracertで最後のping時間（34ミリ秒）と、pingを発行したときに受け取った時間（34ミリ秒）を見ると、これらは同じです。 tracertプログラムはpingよりも遅くはありません。
Tracerouteがどのように機能するかを読むことをお勧めします。
http://en.wikipedia.org/wiki/Traceroute
ニューヨークからサンフランシスコへのドライブのようなpingを見ることができます。それには200時間かかります（スイス出身で、米国の距離に慣れていない）
しかし、ドライバーはニューヨークに戻って、サンフランシスコにいたことを伝えなければなりません。あなたは時計を見て、今度は彼が距離に400時間かかったと計算します。これがPingの機能です。 Tracerouteの機能は次のとおりです。運転手にニューヨークからサンフランシスコまで運転するように伝え、交差点に来るたびに戻ってその名前を教えてください。それで彼は途中で、最初のいくつかの交差点はニューヨークにあります。ですから、彼はあなたに車で戻り、交差点の名前を教えてくれます。しかし、彼がさらに遠くに行くとき、彼はあなたに戻るのにより長くかかります。等々...
つまり、運転時間をすべてカウントすると、彼は途中ですべての交差点を報告するのに、サンフランシスコまで車で運転する必要がある場合よりもはるかに長い時間がかかります。これがあなたのためにいくつかのことを晴らしてくれることを願っています...
後世のために、正しい答えはどれも非常に明確ではないので...
-
Tracerouteに表示される各時間は、マシン（またはtracerouteを実行しているマシン）からその特定のノードまでの合計時間です。
つまり、2番目のノードに表示される時間は、ノード1と2の間の時間ではなく、ソース、1番目のノード、2番目のノードの間の合計時間です。
したがって、平均して、各ノードに表示される時間は、その特定のノードに「直接」pingした場合に得られる時間とほぼ一致するはずです（実際には、トレースルートよりも直接的なものではありません...通常は同じパスをたどります）インターネット上で）。
「ラグスパイク」のようなものがあることを覚えておいてください。ラグの原因を見つける最も正確な方法は、バッチファイルを使用して繰り返しでtracerouteを実行し（Windowsを使用している場合）、常に高い数値を持つ最も近い（最も小さい番号の）ノードを見つけることです。
-
バッチファイルの場合は、メモ帳を開き、次の3行を入力します。
:start
tracert -d www.google.com
goto start
次に「Trace.bat」として保存しますが、保存する前に保存ダイアログのファイルタイプを「すべてのファイル」に変更してください。変更しないと、テキストファイルとして保存されます。
これを開くと、（googleへの）tracerouteが常に実行されます。ウィンドウを選択した状態でctrl + cを押すと停止できます。
-
もちろん、「www.google.com」を好きなアドレスに変更することで、tracerouteの実行先を変更できます。
解決されたホスト名を表示したい場合は、「-d」オプションを削除することもできますが、これにより、各ノードのDNSサーバーからホスト名を取得するためにtracerouteに時間がかかります（実際の結果自体は変更されません） ）。
最後に、時間が多いノードを見つけて、問題が発生する前に別のノードが存在する場合に備えて、その特定のノードへのtracerouteを実行したい場合は、「www.google.com」をそのノードのIPアドレスまたはホスト名に変更できます= OR -hオプションを使用して、検索するノードの数を指定できます...
:start
tracert -d -h 5 www.google.com
goto start
Tracerouteは常に、時間の累積ではなく、宛先までの平均を示します。つまり、あなたの場合、pingとtracerouteは34ミリ秒です。
Tracerouteがあなたの提案したことを行うとしたら、その出力はまったく読めなくなります。
宛先の応答時間だけに関心がある場合は、pingで十分です。tracerouteは、宛先へのルートで何かをデバッグする必要がある場合に使用します。さらに、あなたと宛先の間のすべてのホップはルーターであり、ほとんどの場合、ルーターは何をすべきか、つまり最初にパケットをルーティングし、次にpingまたはtracerouteに応答する（つまり、最初のケース） icmp echo reply、2番目のケースでは、icmp time exceeded）そして、多くの場合、応答が遅くなります（まったく応答する場合）。
実際、これは基本的に、PINGがICMP要求をネットワーク経由でDNSおよび他のネットワークのアプライアンスに送信したことが原因です。
ただし、Tracerouteは、TTLが本当に短いので、多くのパケットを送信します。
たとえば、座席からwww.google.comに参加しようとした場合、tracerouteはTTL 1に設定されたパケットをwww.google.comに送信し、最初の遭遇からの応答を待ちますネットワークのアプライアンス。
次に、Tracerouteは最初のネットワークアプライアンスのIPを画面に表示します。その後、同じことを行いますが、今回はTTL 2に設定します。
最後に、Tracerouteは、送信ごとにネットワークのアプライアンスの応答を待機しているため、約半分の時間待機しました。
回答
tracerouteが遅い理由は次のとおりです。
- ホストに到達するまで、すべてのルーターに順番にpingを送信します（正確な実装に応じて、順次）。
*があると最も遅くなります。これは、指定されたルーターがパケットを確認応答せず、代わりに要求がタイムアウトしたことを意味します。デフォルトのタイムアウトは5秒で、tracerouteはデフォルトで3つのパケットを送信するため、途中の1台のルーターが応答しなかったことがわかるまでに15秒かかります（* * *）。1
スピードアップ
ルーターごとに2つのプローブのみを送信し、タイムアウトを3秒に短縮することで、tracerouteを高速化できます。次に例を示します。
traceroute -q 2 -w 3 google.com
バックグラウンド
Tracerouteコマンドは、パケットがどのようにルーティングされるかを確認するために使用されます。これは、1から始めて、TTL valuesを増やしてパケットを送信することで機能します。したがって、最初のルーターがパケットを取得し、 TTL値を1つ減らして、パケットをドロップします。ルーターは、ICMP Time Exceededメッセージを私たちに送り返します次に、次のパケットはTTL of 2になるため、最初のルーターを通過しますが、2番目のルーターに到達するとTTL =は0であり、別のICMP Time Exceededメッセージを返します。Tracerouteは、パケットを送信およびドロップするときに、最終的に宛先に到達してICMPエコー応答メッセージを取得するまで、パケットが通過するルーターのリストを作成するため、このように機能します。2
ICMP Time Exceededは、リクエストがタイムアウトしたときとは異なります。後者の場合はまったく応答がありませんが、前者の場合は応答があります。
速度を上げるために、次のpingを実行する前にルーターからの応答を待つ必要はありません。
ただし、最近のバージョンのtracerouteプログラムは、一度に1つのパケットを送信するだけではありません。速度を上げるためは、ホップカウントが異なる複数のパケットを一度に送信するので、プログラムは、各ルーターが応答するのを待たずに、次のパケット。３
1 出典： tracerouteの場合の「***」の意味
2 ソース： https://linuxjourney.com/lesson/traceroute
３ ソース： https://www.Perl.com/article/how-does-traceroute-work-/