でmtrmanページ、それが読み取ります。
mtrは、tracerouteとpingプログラムの機能を単一のネットワーク診断ツールに統合します
私mtrは多くを使用し、それがはるかに高速であることを見つけますtraceroute。本能的に、mtr私は即座に答えを与えますが、traceroute各IPアドレスを毎秒リストします。自分のコンピューターでは、とを使用time mtr www.google.comしtime traceroute www.google.comました。結果は21.9秒VS 6.1秒です。
問題はなぜですか？のでmtr = ping + traceroute、それは遅くなるか、少なくともと同じという意味ではありませんtraceroute。
誰もが合理的かつ詳細な答えをくれますか？
回答:
これらのツールの速度が異なる主な理由は、並列処理です。もう1つの要因は、ホップが応答していないと見なされるまでに応答を待機する時間です。逆引きDNSが実行される場合、同様にそれを待つ必要があります。リバースDNSを無効にすると、プレーンなtracerouteコマンドがはるかに高速になります。
もう1つの重要な違いは言及していませんが、2つのツールが出力をレンダリングする方法です。Tracerouteは、トップダウンで出力を生成します。Mtrは出力を別の方法でレンダリングします。この場合、mtrは戻って前の行の出力を更新できます。
これは、後の応答によって出力が不正確になった場合、mtrが戻って更新できるため、mtrは出力が利用可能になるとすぐに表示できることを意味します。tracerouteは戻って出力を更新できないため、最終的に表示する内容を決定するまで待機する必要があります。
たとえば、ホップ番号2が応答しない場合（これは複数のISPで見られる症状です）、tracerouteはホップ番号1を表示し、しばらく待ってからホップ番号2と3を表示します。 tracerouteはホップ番号2からの応答を待機しているため、3は到着していません。後で到着します。
並列処理が多すぎると、出力が不正確になる可能性があります。いくつかのシナリオでは、返信できるパケットの数に制限があります。そのような場合にパケットを送信してもプロセスは高速化されませんが、送信されるパケットが増えて同じ数の応答が返されるため、パケットの損失が多くなります。
この1つの例は、ルート上のホップがARP要求に応答しない場合です。通常、最初のパケットがARP要求をトリガーし、ARP要求がタイムアウトする前にさらにパケットが到着すると、それらのパケットの最後のパケットのみがバッファリングされ、応答が返されます。
別の違いは、ツールがさらにホップの表示を停止する前に、応答のないホップがいくつ表示されるかです。tracerouteコマンドは、要求された数のホップ（デフォルトでは30）継続しますが、mtrコマンドは応答なしで5ホップを超えるとすぐに停止します。
tracerouteコマンドは、1つのプローブに制限すると、ホップごとに3つのプローブを送信し-q 1、結果は同等になります
time mtr -r -c 1 google.com
.
.
.
real 0m2.640s
user 0m0.003s
sys 0m0.018s
time traceroute6 -q 1 google.com
.
.
.
real 0m0.445s
user 0m0.006s
sys 0m0.007s
比較可能なテスト間の主な違いは、DNSクエリの時間とパスの違いに関連すると考えられます。私のtracerouteはmtrよりも高速ですが、これは常にそうであるとは限りません。
主な理由は、tracerouteの実行方法です。TTLが1のUDP（またはWindows上のICMP）パケットを最初のホストに送信し、タイムアウト応答を受信する（または内部タイムアウトを渡す）と、TTLを持つ次のホストの次のパケットを生成します2つ、など（各ホストのTTLに1を追加）。したがって、tracerouteの合計時間には、各ホストのパケットの送受信が順番に含まれます。
mtrは、パケットがたどるパスを決定した後、すべてのICMP ECHOパケットを並行して送信します。
[mtr] investigates the network connection between the host mtr runs on and a user-specified destination host. After it determines the address of each network hop between the machines