作者：蘇欣
校隊：https://cloud.tencent.com/developer/article/1491610
常用的 ping，tracert，nslookup 一般用來判斷主機的網絡連通性，其實 Linux 下有一個更好用的網絡聯通性判斷工具，它可以結合ping nslookup tracert 來判斷網絡的相關特性，這個指令就是 mtr。mtr 全稱 my traceroute，是一個把 ping 和 traceroute 合并到一個程式的網絡診斷工具。
traceroute預設使用UDP資料包探測，而mtr預設使用ICMP封包探測，ICMP在某些路由節點的優先級要比其他資料包低，是以測試得到的資料可能低于實際情況。
安裝方法
1.Windows系統可以直接在https://cdn.ipip.net/17mon/besttrace.exe下載下傳BestTrace工具并安裝。也可以在https://github.com/oott123/WinMTR/releases GitHub上下載下傳MTR專用工具，該工具為免安裝，下載下傳後可以直接使用。
2.Linux可以直接運作指令進行安裝。
# Debian/Ubuntu 系統
apt install mtr
# RedHat/CentOS 系統
yum install mtr
3.Apple用戶端可以在App store搜尋Best NetTools下載下傳安裝
4.Android用戶端：可以在Google Play上下載下傳TracePing，但是由于國内Google Play無法通路，筆者自行下載下傳下來，可以直接通路 https://dwz.cn/KCdNPH4c 下載下傳TracePing。
使用
MTR使用非常簡單，檢視本機到 qq.com 的路由以及連接配接情況直接運作如下指令：
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資料包的大小
mtr -s 100 qq.com
100 bytes 資料包會用來發送，測試，如果設定為負數，則每一次發送的資料包的大小都會是一個随機數。
- -c
指定發送數量
mtr -c 100 qq.com
- -n
不進行主機解釋
使用 -n 選項來讓 mtr 隻輸出 IP，而不對主機 host name 進行解釋
mtr -n qq.com MTR結果分析
當我們分析 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 傳輸 還是确定有丢包的現象？此時需要檢視下一跳。如果下一跳沒有丢包現象，說明上一條是人為限制的。如下示例：
人為限制MTR丢包
在此例中，第4跳發生了丢包現象，但是接下來幾條都沒任何丢包現象，說明第二跳的丢包是人為限制的。如果在接下來的幾條中都有丢包，那就可能是第二跳有問題了。請記住，ICMP 包的速率限制和丢失可能會同時發生。
MTR丢包截圖
從上面的圖中，您可以看從第13跳和第17跳都有 10% 的丢包率，從接下來的幾跳都有丢包現象，但是最後15,16跳都是100%的丢包率，我們可以猜測到100%的丢包率除了網絡糟糕的原因之前還有人為限制 ICMP。是以，當我們看到不同的丢包率時，通常要以最後幾跳為準。
還有很多時候問題是在資料包傳回途中發生的。資料包可以成功的到達目的主機，但是傳回過程中遇到“困難”了。是以，當問題發生後，我們通常需要收集反方向的 MTR 報告。
此外，網際網路設施的維護或短暫的網絡擁擠可能會帶來短暫的丢包率，當出現短暫的10%丢包率時候，不必擔心，應用層的程式會彌補這點損失。
網絡延遲
除了可以通過MTR報告檢視丢包率，我們也還可以看到本地到目的之間的時延。因為是不通的位置，延遲通常會随着條數的增加而增加。是以，延遲通常取決于節點之間的實體距離和線路品質。
MTR檢視網絡延遲
從上面的MTR報告截圖中，我們可以看到從第11跳到12跳的延遲猛增，直接導緻了後面的延遲也很大，一般有可能是11跳到12跳屬于不通地域，實體距離導緻時延猛增，也有可能是第12條的路由器配置不當，或者是線路擁塞。需要具體問題進行具體的分析。
然而，高延遲并不一定意味着目前路由器有問題。延遲很大的原因也有可能是在傳回過程中引發的。從這份報告的截圖看不到傳回的路徑，傳回的路徑可能是完全不同的線路，是以一般需要進行雙向MTR測試。
注：ICMP 速率限制也可能會增加延遲，但是一般可以檢視最後一條的時間延遲來判斷是否是上述情況。
根據MTR結果解決網絡問題