為什麼 mtr 比 traceroute 快得多？

在mtr手冊頁中，它顯示：

mtr 在單個網路診斷工具中結合了 traceroute 和 ping 程序的功能

我用mtr了很多，發現它比traceroute. 本能地，mtr給我答案，同時每秒鐘traceroute列出每個 IP 地址。在我自己的電腦上，我使用time mtr www.google.comand time traceroute www.google.com，結果是 21.9s VS 6.1s。

問題是為什麼？既然mtr = ping + traceroute, 這是否意味著它更慢或至少與traceroute.

誰能給我一個合理而詳細的答案？

並行性是這些工具速度變化的主要原因。另一個影響因素是他們在認為躍點沒有響應之前等待回复的時間。如果執行反向 DNS，您也必須等待。如果禁用反向 DNS，普通的 traceroute 命令會更快。

另一個我沒有提到的重要區別是這兩個工具如何呈現輸出。Traceroute 按自上而下的順序生成輸出。Mtr 以不同的方式呈現輸出，其中 mtr 可以返回並更新前幾行的輸出。

這意味著 mtr 可以在輸出可用時立即顯示，因為如果以後的回复導致輸出不准確，mtr 可以返回並更新它。由於 traceroute 無法返回並更新輸出，它必須等到它最終決定要顯示什麼。

例如，如果第 2 跳沒有響應（這是我在多個 ISP 上看到的症狀），traceroute 將顯示第 1 跳，然後等待一段時間，然後才會顯示第 2 和第 3 跳。即使來自跳數的回复3 已到達它沒有顯示，因為 traceroute 仍在等待來自 2 號躍點的回复。 Mtr 沒有該限制，可以顯示來自 3 號躍點的回复，並且仍然返回以顯示來自 2 號躍點的回复，如果它稍後到達。

過多的並行性會導致輸出變得不准確。在某些情況下，您可以獲得回复的數據包數量是有限的。在這些情況下發送更多數據包不會加快處理速度，但是會導致更多封包遺失，因為您收到相同數量的回复並發送更多數據包。

這方面的一個例子是當路由上的一跳不回复 ARP 請求時。通常第一個數據包會觸發 ARP 請求，如果在 ARP 請求超時之前有更多數據包到達，則只有最後一個數據包會被緩衝並得到回复。

另一個區別是在工具停止顯示更多躍點之前將顯示多少沒有響應的躍點。我已經看到 traceroute 命令根據請求繼續進行盡可能多的躍點（預設為 30），而 mtr 命令將在它通過五個躍點後立即停止而沒有響應。

引用自：https://serverfault.com/questions/585862