網路丟包，網路延遲，這款神器幫你搞定所有

常用的 ping，tracert，nslookup 一般用來判斷主機的網路連通性，其實 Linux 下有一個更好用的網路聯通性判斷工具，它可以結合ping nslookup traceroute 來判斷網路的相關特性，這個命令就是 mtr。

mtr 全稱 my traceroute，是一個把 ping 和 traceroute 合併到一個程式的網路診斷工具。

traceroute 預設使用 UDP 資料包探測，而 mtr 預設使用 ICMP 報文探測，ICMP 在某些路由節點的優先順序要比其他資料包低，所以測試得到的資料可能低於實際情況。

安裝方法

1. Windows 系統可以直接在下載 BestTrace 工具並安裝。也可以在 GitHub上下載 MTR專用工具，該工具為免安裝，下載後可以直接使用。

2. Linux 可以直接執行命令進行安裝。

# Debian/Ubuntu 系統sudo apt install mtr# RedHat/CentOS 系統sudo yum install mtr

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

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

使用

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

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

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

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