常用的 ping，tracert，nslookup 一般用來判斷主機的網絡連通性，其實 Linux 下有一個更好用的網絡聯通性判斷工具，它可以結合ping nslookup tracert 來判斷網絡的相關特性，這個指令就是 mtr。
mtr 全稱 my traceroute，是一個把 ping 和 traceroute 合并到一個程式的網絡診斷工具。
traceroute 預設使用 UDP 資料包探測，而 mtr 預設使用 ICMP 封包探測，ICMP 在某些路由節點的優先級要比其他資料包低，是以測試得到的資料可能低于實際情況。
Windows 系統可以直接在
Linux 可以直接運作指令進行安裝。
Apple 用戶端可以在 App store 搜尋 Best NetTools 下載下傳安裝
Android 用戶端：可以在 Google Play 上下載下傳 TracePing，但是由于國内 Google Play 無法通路，筆者自行下載下傳下來，可以直接通路 https://dwz.cn/KCdNPH4c 下載下傳TracePing。
MTR 使用非常簡單，檢視本機到 qq.com 的路由以及連接配接情況直接運作如下指令：
具體輸出的參數含義為：
第一列是IP位址
丢包率：Loss
已發送的包數：Snt
最後一個包的延時：Last
平均延時：Avg
最低延時：Best
最差延時：Wrst
方差（穩定性）：StDev
-r or —report
使用 mtr -r qq.com 來列印報告，如果不使用 -r or —report 參數 mtr 會不斷動态運作。使用 report 選項， mtr 會向 qq.com 主機發送 10 個 ICMP 包，然後直接輸出結果。通常情況下 mtr 需要幾秒鐘時間來輸出報告。mtr 報告由一系列跳數組成，每一跳意味着資料包通過節點或者路由器來達到目的主機。
一般情況下 mtr 前幾跳都是本地 ISP，後幾跳屬于服務商比如 騰訊資料中心，中間跳數則是中間節點，如果發現前幾跳異常，需要聯系本地 ISP 服務提供上，相反如果後幾跳出現問題，則需要聯系服務提供商，中間幾跳出現問題，則需要聯系營運商進行處理
預設使用 -r 參數來生成報告，隻會發送10個資料包，如果想要自定義資料包數量，可以使用 -c 參數
-s or —packetsize
使用 -s 來指定ping資料包的大小
100 bytes 資料包會用來發送，測試，如果設定為負數，則每一次發送的資料包的大小都會是一個随機數。
-c
指定發送數量
-n
不進行主機解釋
使用 -n 選項來讓 mtr 隻輸出 IP，而不對主機 host name 進行解釋
當我們分析 MTR 報告時候，最好找出每一跳的任何問題。除了可以檢視兩個伺服器之間的路徑之外，MTR 在它的七列資料中提供了很多有價值的資料統計報告。Loss% 列展示了資料包在每一跳的丢失率。Snt 列記錄的多少個資料包被送出。使用 –report 參數預設會送出10個資料包。如果使用 –report-cycles=[number-of-packets] 選項，MTR 就會按照 [number-of-packets] 指定的數量發出 ICMP 資料包。
Last, Avg, Best 和 Wrst 列都辨別資料包往返的時間，使用的是毫秒（ ms ）機關表示。Last 表示最後一個資料包所用的時間， Avg 表示評價時間， Best 和 Wrst 表示最小和最大時間。在大多數情況下，平均時間（ Avg）列需要我們特别注意。
最後一列 StDev 提供了資料包在每個主機的标準偏差。如果标準偏差越高，說明資料包在這個節點的延時越不相同。标準偏差會讓您了解到平均延時是否是真的延時時間的中心點，或者測量資料受到某些問題的幹擾。
例如，如果标準偏差很大，說明資料包的延遲是不确定的。一些資料包延遲很小（例如：25ms），另一些資料包延遲很大（例如：350ms）。當10個資料包全部發出後，得到的平均延遲可能是正常的，但是平均延遲是不能很好的反應實際情況的。如果标準偏差很高，使用最好和最壞的延遲來确定平均延遲是一個較好的方案。
在大多數情況下，您可以把 MTR 的輸出分成三大塊。根據配置，第二或第三跳一般都是您的本地 ISP，倒數第二或第三跳一般為您目的主機的ISP。中間的節點是資料包經過的路由器。
當分析 MTR 的輸出時，您需要注意兩點：loss 和 latency。
如果在任何一跳上看到 loss 的百分比，這就說明這一跳上可能有問題了。當然，很多服務提供商人為限制 ICMP 發送的速率，這也會導緻此問題。那麼如何才能指定是人為的限制 ICMP 傳輸 還是确定有丢包的現象？此時需要檢視下一跳。如果下一跳沒有丢包現象，說明上一條是人為限制的。如下示例：
在此例中，第4跳發生了丢包現象，但是接下來幾條都沒任何丢包現象，說明第二跳的丢包是人為限制的。如果在接下來的幾條中都有丢包，那就可能是第二跳有問題了。請記住，ICMP 包的速率限制和丢失可能會同時發生。
從上面的圖中，您可以看從第13跳和第17跳都有 10% 的丢包率，從接下來的幾跳都有丢包現象，但是最後15,16跳都是100%的丢包率，我們可以猜測到100%的丢包率除了網絡糟糕的原因之前還有人為限制 ICMP。是以，當我們看到不同的丢包率時，通常要以最後幾跳為準。
還有很多時候問題是在資料包傳回途中發生的。資料包可以成功的到達目的主機，但是傳回過程中遇到“困難”了。是以，當問題發生後，我們通常需要收集反方向的 MTR 報告。
此外，網際網路設施的維護或短暫的網絡擁擠可能會帶來短暫的丢包率，當出現短暫的10%丢包率時候，不必擔心，應用層的程式會彌補這點損失。
除了可以通過MTR報告檢視丢包率，我們也還可以看到本地到目的之間的時延。因為是不通的位置，延遲通常會随着條數的增加而增加。是以，延遲通常取決于節點之間的實體距離和線路品質。
從上面的MTR報告截圖中，我們可以看到從第11跳到12跳的延遲猛增，直接導緻了後面的延遲也很大，一般有可能是11跳到12跳屬于不通地域，實體距離導緻時延猛增，也有可能是第12條的路由器配置不當，或者是線路擁塞。需要具體問題進行具體的分析。
然而，高延遲并不一定意味着目前路由器有問題。延遲很大的原因也有可能是在傳回過程中引發的。從這份報告的截圖看不到傳回的路徑，傳回的路徑可能是完全不同的線路，是以一般需要進行雙向MTR測試。
注：ICMP 速率限制也可能會增加延遲，但是一般可以檢視最後一條的時間延遲來判斷是否是上述情況。
MTR 報告顯示的路由問題大都是暫時性的。很多問題在24小時内都被解決了。大多數情況下，如果您發現了路由問題，ISP 提供商已經監視到并且正在解決中了。當您經曆網絡問題後，可以選擇提醒您的 ISP 提供商。當聯系您的提供商時，需要發送一下 MTR 報告和相關的資料。沒有有用的資料，提供商是沒有辦法去解決問題的。
然而大多數情況下，路由問題是比較少見的。比較常見的是因為實體距離太長，或者上網高峰，導緻網絡變的很慢。尤其是跨越大西洋和太平洋的時候，網絡有時候會變的很慢。這種情況下，建議就近接入客戶的節點。
來源：https://cloud.tencent.com/developer/article/1491610
（版權歸原作者所有，侵删）