網絡排查神器 MTR

常用的 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專用工具，該工具爲免安裝，下載後可以直接使用。

  1. Linux 可以直接運行命令進行安裝。

  2. Apple 客戶端可以在 App store 搜索 Best NetTools 下載安裝

  3. Android 客戶端：可以在 Google Play 上下載 TracePing，但是由於國內 Google Play 無法訪問，筆者自行下載下來，可以直接訪問 https://dwz.cn/KCdNPH4c 下載 TracePing。

使用

MTR 使用非常簡單，查看本機到 qq.com 的路由以及連接情況直接運行如下命令：

mtr qq.com

MTR qq.com 測試界面 

具體輸出的參數含義爲：

參數說明

-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 結果解決網絡問題

MTR 報告顯示的路由問題大都是暫時性的。很多問題在 24 小時內都被解決了。大多數情況下，如果您發現了路由問題，ISP 提供商已經監視到並且正在解決中了。當您經歷網絡問題後，可以選擇提醒您的 ISP 提供商。當聯繫您的提供商時，需要發送一下 MTR 報告和相關的數據。沒有有用的數據，提供商是沒有辦法去解決問題的。

然而大多數情況下，路由問題是比較少見的。比較常見的是因爲物理距離太長，或者上網高峯，導致網絡變的很慢。尤其是跨越大西洋和太平洋的時候，網絡有時候會變的很慢。這種情況下，建議就近接入客戶的節點。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/IxOyxPUvDfGbnpA0wxBRCw

猜你喜歡