使用 MTR 诊断网络问题
為什么80%的碼農都做不了架構師？>>> ??
使用 MTR 診斷網絡問題
每日一貼???2015年5月26日???3 條評論
MTR 是一款強大的網絡診斷工具，網絡管理員使用 MTR 可以診斷和隔離網絡問題，并且為上游 ISP 提供有用的網絡狀態報告。
MTR 是傳統 traceroute 命令的進化版，并且可以提供強大的數據樣本，因為他集合了 traceroute 和 ping 這兩個命令的精華。本文帶您深入了解 MTR ，從數據如何生成，到如果正確理解報告樣本并得出相應的結論。
關于網絡診斷技術的基本理論請參考?network diagnostics?.如果您懷疑您的 Linux 系統有其他問題，請參考system diagnostics?。最后，我們假定您已經掌握了?getting started guide?(入門指南) 。
網絡診斷相關的背景知識
網絡診斷工具 例如 ping traceroute mtr 都使用的 “ICMP” 包來測試 Internet 兩點之間的網絡連接狀況。當用戶使用 ping 命令 ping 網絡上的主機后， ICMP 包將會發送到目的主機，然后在目的主機返回響應。這樣，就可以得知本機到目的主機 ICMP 包傳輸所使用的往返時間。
相對于其他命令僅僅收集傳輸路徑或響應時間，MTR 工具會收集更多的信息，比如 連接狀態，連接可用性，以及傳輸路徑中主機的響應性。由于這些額外的信息，我們建議您盡可能完整的展現 Internet 兩個主機之間的網絡連接信息。接下來我們講述如何安裝 MTR 軟件，以及如何看懂這款軟件的輸出結果。
安裝 MTR
在 Debian 和 Ubuntu 系統中，使用如下命令更新系統，然后安裝 MTR：
apt-get update apt-get upgrade apt-get install mtr-tiny在 CentOS 和 Fedora 系統中，使用如下命令更新系統，并安裝 MTR：
yum update yum install mtr在 Arch Linux 系統中，按照如下命令更新系統并安裝 MTR：
pacman -Sy pacman -S mtr如果您的本機使用的是 Linux 系統，并且想用 MTR 測試網絡狀況，請按照如上教程安裝。
如果您的本機使用的 Mac OS X 系統，可以使用?Homebre?或?MacPorts?來安裝 MTR。使用 Homebrew 安裝 MTR：
brew install mtr使用 MacPorts 安裝 MTR：
port install mtr如果您的本機使用的是 Windows 系統，您可以使用 “WinMTR”。可以從這里下載：WinMTR?.
因為 MTR 提供兩個主機之間的網絡路徑圖，您可以把它想象成一款定向工具。另外，因為地址位置或上游ISP路由器的原因，路徑有時候可能會有很大的不同。所以我們建議您盡可能多的收集 MTR 的報告信息。
如果您遇到網絡方面的問題， Linode 的技術支持經常建議您收集雙向的 MTR 報告（從 Linode 出發和到 Linode 的往返路徑）。這是因為有時候網絡狀況從一個方向不會出現錯誤，但是從另一個方向會出現丟包現象。當出現網絡問題時候，雙向 MTR 報告是十分有用的。
在本文中，運行 mtr 命令的主機稱為 源主機，被查詢的主機稱為 目的主機。
在 Unix-based 系統中使用 MTR
當在Linux 或 Mac OS X 系統中安裝 MTR 后，您可以使用如下命令來產生 MTR 報告：
mtr -rw [destination_host]例如，我們需要測試到 example.com 的路由信息和網絡連接質量，在源主機上運行如下命令：
mtr -rw example.com如果我們遇到網絡問題，需要聯系 Linode 的技術支持，Linode 需要我們提供雙向的 MTR 報告。第一份是從您的本機到 Linode VPS 的 MTR 報告，命令如下：
mtr -rw 87.65.43.21使用您的Linode VPS 的IP地址替換 87.65.43.21 。
然后我們需要搜集從您的Linode VPS 返回到您的本機的 MTR 報告，命令如下：
mtr -rw 12.34.56.78請使用您的本地公網IP地址替換 12.34.56.78 。如果您不確定您的本地公網IP地址，您可以使用相關的第三方服務，如果 WhatIsMyIP.com。（譯者著：國內可以使用 ip.c、ip138.com 、ipip.net 等第三方服務）
注
我們使用 rw 參數是為了方便讓 Linode 的技術支持看到更多的網絡信息。
r 產生報告信息（–report 的縮寫）
w 報告中帶有 hostname 信息，Linode 技術支持可以看到每一跳的完整 hostname （–report-wide 的縮寫）
在 Windows 系統下使用 MTR
首先，Windows 下的 MTR 有 GUI 的，運行 WinMTR，輸入目的地址，然后選擇開始即可，您就會看到輸出內容。
另外，您還需要使用 Linux 版本的 MTR 來產生從 Linode 到您本地的返回線路網絡狀況。（因為目前 Linode 僅有Linux 的VPS，哈哈）
如何讀懂 MTR 報告
因為 MTR 報告包括了豐富的信息，新手第一次閱讀有點困難。下面是我本地到 google.com 的測試報告：
$ mtr --report google.com HOST: example????????????????? Loss%?? Snt?? Last?? Avg? Best? Wrst StDev1. inner-cake??????????????????? 0.0%??? 10??? 2.8?? 2.1?? 1.9?? 2.8?? 0.32. outer-cake??????????????????? 0.0%??? 10??? 3.2?? 2.6?? 2.4?? 3.2?? 0.33. 68.85.118.13????????????????? 0.0%??? 10??? 9.8? 12.2?? 8.7? 18.2?? 3.04. po-20-ar01.absecon.nj.panjde? 0.0%??? 10?? 10.2? 10.4?? 8.9? 14.2?? 1.65. be-30-crs01.audubon.nj.panjd? 0.0%??? 10?? 10.8? 12.2? 10.1? 16.6?? 1.76. pos-0-12-0-0-ar01.plainfield? 0.0%??? 10?? 13.4? 14.6? 12.6? 21.6?? 2.67. pos-0-6-0-0-cr01.newyork.ny.? 0.0%??? 10?? 15.2? 15.3? 13.9? 18.2?? 1.38. pos-0-4-0-0-pe01.111eighthav? 0.0%??? 10?? 16.5? 16.2? 14.5? 19.3?? 1.39. as15169-3.111eighthave.ny.ib? 0.0%??? 10?? 16.0? 17.1? 14.2? 27.7?? 3.910. 72.14.238.232???????????????? 0.0%??? 10?? 19.1? 22.0? 13.9? 43.3? 11.111. 209.85.241.148??????????????? 0.0%??? 10?? 15.1? 16.2? 14.8? 20.2?? 1.612. lga15s02-in-f104.1e100.net??? 0.0%??? 10?? 15.6? 16.9? 15.2? 20.6?? 1.7使用 mtr –report google.com 命令來輸出這篇報告。使用 report 選項可以給 google.com 主機發送10個 ICMP 包，然后輸出報告。如果我們不使用 –report 參數， mtr 會不斷的動態運行。在動態模式下， mtr 的輸出結果表述每個主機的往返時間。大多數情況下，使用 –report 參數就可以提供足夠的數據了。
在命令下面，就是 MTR 產生的輸出報告 。在通常情況下， MTR需要幾秒鐘的時間來輸出報告，但是偶爾可能需要更長的時間。MTR 報告是由一系列跳數組成的（在上述例子中是12跳）。“跳”意味著節點，或路由器，數據包通過它們才能到達目的主機。在上面例子中，數據包經過本地網絡的“內層”和“外層”，然后到達 “68.85.118.13”，然后再到一系列的域名主機。主機的域名是通過反向 DNS 查找確定的。如果您想忽略 rDNS 查找，您可以使用 –no-dns 參數，使用 –no-dns 參數后，報告結果如下：
%? mtr? --no-dns --report google.com HOST: deleuze???????????????????? Loss%?? Snt?? Last?? Avg? Best? Wrst StDev1. 192.168.1.1?????????????????? 0.0%??? 10??? 2.2?? 2.2?? 2.0?? 2.7?? 0.22. 68.85.118.13????????????????? 0.0%??? 10??? 8.6? 11.0?? 8.4? 17.8?? 3.03. 68.86.210.126???????????????? 0.0%??? 10??? 9.1? 12.1?? 8.5? 24.3?? 5.24. 68.86.208.22????????????????? 0.0%??? 10?? 12.2? 15.1? 11.7? 23.4?? 4.45. 68.85.192.86????????????????? 0.0%??? 10?? 17.2? 14.8? 13.2? 17.2?? 1.36. 68.86.90.25?????????????????? 0.0%??? 10?? 14.2? 16.4? 14.2? 20.3?? 1.97. 68.86.86.194????????????????? 0.0%??? 10?? 17.6? 16.8? 15.5? 18.1?? 0.98. 75.149.230.194??????????????? 0.0%??? 10?? 15.0? 20.1? 15.0? 33.8?? 5.69. 72.14.238.232???????????????? 0.0%??? 10?? 15.6? 18.7? 14.1? 32.8?? 5.910. 209.85.241.148??????????????? 0.0%??? 10?? 16.3? 16.9? 14.7? 21.2?? 2.211. 66.249.91.104???????????????? 0.0%??? 10?? 22.2? 18.6? 14.2? 36.0?? 6.5當我們研究 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，目的地是您的 Linode VPS，一般前三跳屬于您的本地 ISP，后三跳屬于 Linode 數據中心這邊的。中間的條數是屬于中間節點的。當您在本地運行 MTR，如果您在前幾跳發現異常，請聯系您本地的 ISP 服務提供商。相反，如果您在接近目的地的幾跳發現問題，請聯系您目的地的服務器提供商（例如：Linode）。如果您的問題出現在中間幾跳，很不幸，兩邊的服務提供商的能力有限，可能不能完全為您解決問題嘍。
分析 MTR 報告
核查數據包的丟失
當分析 MTR 的輸出時，您需要注意兩點： loss 和 latency。首先，讓我們討論一下 loss。如果您在任何一跳上看到 loss 的百分比，這就說明這一跳上可能有問題了。當然，很多服務提供商人為限制 ICMP 發送的速率，這也會導致此問題。那么如何才能指定是人為的限制 ICMP 傳輸 還是確定有丟包的現象？我們需要查看下一跳。如果下一跳沒有丟包現象，說明上一條是人為限制的。如下示例：
root@meiriyitie.com:~# mtr –report www.google.com
HOST: example?????????????? Loss%?? Snt?? Last?? Avg? Best? Wrst StDev
1. 63.247.74.43????????????????? 0.0%??? 10??? 0.3?? 0.6?? 0.3?? 1.2?? 0.3
2. 63.247.64.157??????????????? 50.0%??? 10??? 0.4?? 1.0?? 0.4?? 6.1?? 1.8
3. 209.51.130.213??????????????? 0.0%??? 10??? 0.8?? 2.7?? 0.8? 19.0?? 5.7
4. aix.pr1.atl.google.com??????? 0.0%??? 10??? 6.7?? 6.8?? 6.7?? 6.9?? 0.1
5. 72.14.233.56????????????????? 0.0%??? 10??? 7.2?? 8.3?? 7.1? 16.4?? 2.9
6. 209.85.254.247??????????????? 0.0%??? 10?? 39.1? 39.4? 39.1? 39.7?? 0.2
7. 64.233.174.46???????????????? 0.0%??? 10?? 39.6? 40.4? 39.4? 46.9?? 2.3
8. gw-in-f147.1e100.net????????? 0.0%??? 10?? 39.6? 40.5? 39.5? 46.7?? 2.2
在此例中，第二跳發生了丟包現象，但是接下來幾條都沒任何丟包現象，說明第二跳的丟包是人為限制的。如果在接下來的幾條中都有丟包，那就可能是第二跳有問題了。請記住，ICMP 包的速率限制和丟失可能會同時發生。如果發生包的丟失情況，我們要用最低百分比來衡量時間情況。為什么這么說呢？請看如下示例：
root@meiriyitie.com:~# mtr –report www.google.com
HOST: localhost?????????????????? Loss%?? Snt?? Last?? Avg? Best? Wrst StDev
1. 63.247.74.43?????????????????? 0.0%??? 10??? 0.3?? 0.6?? 0.3?? 1.2?? 0.3
2. 63.247.64.157????????????????? 0.0%??? 10??? 0.4?? 1.0?? 0.4?? 6.1?? 1.8
3. 209.51.130.213??????????????? 60.0%??? 10??? 0.8?? 2.7?? 0.8? 19.0?? 5.7
4. aix.pr1.atl.google.com??????? 60.0%??? 10??? 6.7?? 6.8?? 6.7?? 6.9?? 0.1
5. 72.14.233.56????????????????? 50.0%?? 10??? 7.2?? 8.3?? 7.1? 16.4?? 2.9
6. 209.85.254.247??????????????? 40.0%?? 10?? 39.1? 39.4? 39.1? 39.7?? 0.2
7. 64.233.174.46???????????????? 40.0%?? 10?? 39.6? 40.4? 39.4? 46.9?? 2.3
8. gw-in-f147.1e100.net????????? 40.0%?? 10?? 39.6? 40.5? 39.5? 46.7?? 2.2
在這個例子中，您可以看打 第3跳和第4跳都有 60% 的丟包率，從接下來的幾跳都有丟包現象，所以不像是人為限制 ICMP 速率的原因。但是最后幾跳都是40%的丟包率，我們可以猜測到60%的丟包率除了網絡糟糕的原因之前還有人為限制 ICMP。所以，當我們看到不同的丟包率時，通常要以最后幾跳為準。
還有很多時候問題是在數據包返回途中發生的。數據包可以成功的到達目的主機，但是返回過程中遇到“困難”了。所以，當問題發生后，我們通常需要收集反方向的 MTR 報告。
此外，互聯網設施的維護或短暫的網絡擁擠可能會帶來短暫的丟包率，當出現短暫的10%丟包率時候，不必擔心，應用層的程序會彌補這點損失。
讀懂網絡延遲
除了可以通過 MTR 報告看到丟包率，我們還可以看到本地到目的主機之間的延時。因為不同的物理位置，延遲通常隨著跳數的增加而增加。所以，延遲通常取決于節點之間的物理距離和線路質量。
例如，在同樣的傳輸距離下，dial-up連接比cable modem連接有更大的延遲。如下示例中顯示 MTR 報告：
root@meiriyitie.com:~# mtr –report www.google.com
HOST: localhost?????????????????? Loss%?? Snt?? Last?? Avg? Best? Wrst StDev
1. 63.247.74.43????????????????? 0.0%??? 10??? 0.3?? 0.6?? 0.3?? 1.2?? 0.3
2. 63.247.64.157???????????????? 0.0%??? 10??? 0.4?? 1.0?? 0.4?? 6.1?? 1.8
3. 209.51.130.213??????????????? 0.0%??? 10??? 0.8?? 2.7?? 0.8? 19.0?? 5.7
4. aix.pr1.atl.google.com??????? 0.0%??? 10? 388.0 360.4 342.1 396.7?? 0.2
5. 72.14.233.56????????????????? 0.0%??? 10? 390.6 360.4 342.1 396.7?? 0.2
6. 209.85.254.247??????????????? 0.0%??? 10? 391.6 360.4 342.1 396.7?? 0.4
7. 64.233.174.46???????????????? 0.0%??? 10? 391.8 360.4 342.1 396.7?? 2.1
8. gw-in-f147.1e100.net????????? 0.0%??? 10? 392.0 360.4 342.1 396.7?? 1.2
在這份報告中，從第三跳到第四跳的延遲猛增，直接導致了后面的延遲也很大。這可能是因為第四跳的路由器配置不當，或者線路很擁堵的原因。
然而，高延遲并不一定意味著當前路由器有問題。這份報告雖然看到第四跳有點問題，但是數據仍然可以正常達到目的主機并且返回給主機。延遲很大的原因也有可能是在返回過程中引發的。我這份報告我們看不到返回的路徑，返回的路徑可能是完全不同的線路，所以我們一般要進行雙向測試了。
ICMP 速率限制也可能會增加延遲，如下：
root@meiriyitie.com:~# mtr --report www.google.com HOST: localhost?????????????????? Loss%?? Snt?? Last?? Avg? Best? Wrst StDev1. 63.247.74.43????????????????? 0.0%??? 10??? 0.3?? 0.6?? 0.3?? 1.2?? 0.32. 63.247.64.157???????????????? 0.0%??? 10??? 0.4?? 1.0?? 0.4?? 6.1?? 1.83. 209.51.130.213??????????????? 0.0%??? 10??? 0.8?? 2.7?? 0.8? 19.0?? 5.74. aix.pr1.atl.google.com??????? 0.0%??? 10??? 6.7?? 6.8?? 6.7?? 6.9?? 0.15. 72.14.233.56????????????????? 0.0%??? 10? 254.2 250.3 230.1 263.4?? 2.96. 209.85.254.247??????????????? 0.0%??? 10?? 39.1? 39.4? 39.1? 39.7?? 0.27. 64.233.174.46???????????????? 0.0%??? 10?? 39.6? 40.4? 39.4? 46.9?? 2.38. gw-in-f147.1e100.net????????? 0.0%??? 10?? 39.6? 40.5? 39.5? 46.7?? 2.2乍一看，第4跳和第5跳直接的延遲很大。但是第5跳之后，延遲又恢復正常了。最后的延遲差不多為 40ms。像這種情況，是不影響實際情況的。因為可能僅僅是第5跳設備限制了 ICMP 傳輸速率的原因。所以我們一般要用最后一跳的實際延遲為準。
常見的 MTR 報告類型
很多網絡問題十分麻煩，并且需要上級網絡提供商來幫助。然而，這里有很多常見的 MTR 報告所描述的網絡問題。如果您正在經歷一些網絡問題，并且想診斷出原因，可以參考如下示例：
目的主機網絡配置不當
在下面這個例子中，數據包在目的地出現了 100% 的丟包。乍一看是數據包沒有到達，其實未必，很有可能是路由器或主機配置不當。
root@meiriyitie.com:~# mtr --report www.google.com HOST: localhost?????????????????? Loss%?? Snt?? Last?? Avg? Best? Wrst StDev1. 63.247.74.43????????????????? 0.0%??? 10??? 0.3?? 0.6?? 0.3?? 1.2?? 0.32. 63.247.64.157???????????????? 0.0%??? 10??? 0.4?? 1.0?? 0.4?? 6.1?? 1.83. 209.51.130.213??????????????? 0.0%??? 10??? 0.8?? 2.7?? 0.8? 19.0?? 5.74. aix.pr1.atl.google.com??????? 0.0%??? 10??? 6.7?? 6.8?? 6.7?? 6.9?? 0.15. 72.14.233.56????????????????? 0.0%??? 10??? 7.2?? 8.3?? 7.1? 16.4?? 2.96. 209.85.254.247??????????????? 0.0%??? 10?? 39.1? 39.4? 39.1? 39.7?? 0.27. 64.233.174.46???????????????? 0.0%??? 10?? 39.6? 40.4? 39.4? 46.9?? 2.38. gw-in-f147.1e100.net???????? 100.0??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.0MTR 報告數據包沒有到達目的主機是因為目的主機沒有發送任何應答。這可能是目的主機防火墻的原因，例如： iptables 配置丟掉 ICMP 包所致。
家庭或辦公室路由器的原因
有時候家庭路由器的原因導致 MTR 報告看起來有點誤導。
% mtr --no-dns --report google.com HOST: deleuze???????????????????? Loss%?? Snt?? Last?? Avg? Best? Wrst StDev1. 192.168.1.1?????????????????? 0.0%??? 10??? 2.2?? 2.2?? 2.0?? 2.7?? 0.22. ???????????????????????????? 100.0??? 10??? 8.6? 11.0?? 8.4? 17.8?? 3.03. 68.86.210.126???????????????? 0.0%??? 10??? 9.1? 12.1?? 8.5? 24.3?? 5.24. 68.86.208.22????????????????? 0.0%??? 10?? 12.2? 15.1? 11.7? 23.4?? 4.45. 68.85.192.86????????????????? 0.0%??? 10?? 17.2? 14.8? 13.2? 17.2?? 1.36. 68.86.90.25?????????????????? 0.0%??? 10?? 14.2? 16.4? 14.2? 20.3?? 1.97. 68.86.86.194????????????????? 0.0%??? 10?? 17.6? 16.8? 15.5? 18.1?? 0.98. 75.149.230.194??????????????? 0.0%??? 10?? 15.0? 20.1? 15.0? 33.8?? 5.69. 72.14.238.232???????????????? 0.0%??? 10?? 15.6? 18.7? 14.1? 32.8?? 5.910. 209.85.241.148??????????????? 0.0%??? 10?? 16.3? 16.9? 14.7? 21.2?? 2.211. 66.249.91.104???????????????? 0.0%??? 10?? 22.2? 18.6? 14.2? 36.0?? 6.5不要為 100% 的丟包率所嚇到，這并不表明這里有問題。你可以看打在接下來幾跳是沒有任何丟包的。
運營商的路由器沒有正確配置
有時候您的運營商的路由器配置原因，導致 ICMP 包永遠不能到達目的地，例如：
root@meiriyitie.com:~# mtr --report www.google.com HOST: localhost?????????????????? Loss%?? Snt?? Last?? Avg? Best? Wrst StDev1. 63.247.74.43????????????????? 0.0%??? 10??? 0.3?? 0.6?? 0.3?? 1.2?? 0.32. 63.247.64.157???????????????? 0.0%??? 10??? 0.4?? 1.0?? 0.4?? 6.1?? 1.83. 209.51.130.213??????????????? 0.0%??? 10??? 0.8?? 2.7?? 0.8? 19.0?? 5.74. aix.pr1.atl.google.com??????? 0.0%??? 10??? 6.7?? 6.8?? 6.7?? 6.9?? 0.15. ????????????????????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.06. ????????????????????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.07. ????????????????????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.08. ????????????????????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.09. ????????????????????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.010. ????????????????????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.0當沒有額外的路由信息時，將會顯示問號（???），下面例子也一樣：
root@meiriyitie.com:~# mtr --report www.google.com HOST: localhost?????????????????? Loss%?? Snt?? Last?? Avg? Best? Wrst StDev1. 63.247.74.43???????????????? 0.0%??? 10??? 0.3?? 0.6?? 0.3?? 1.2?? 0.32. 63.247.64.157??????????????? 0.0%??? 10??? 0.4?? 1.0?? 0.4?? 6.1?? 1.83. 209.51.130.213?????????????? 0.0%??? 10??? 0.8?? 2.7?? 0.8? 19.0?? 5.74. aix.pr1.atl.google.com?????? 0.0%??? 10??? 6.7?? 6.8?? 6.7?? 6.9?? 0.15. 172.16.29.45???????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.06. ???????????????????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.0 7. ???????????????????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.08. ???????????????????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.09. ???????????????????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.010. ???????????????????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.0有時候，一個錯誤配置的路由器，將會在一個環路中不斷發送數據包，如下：
root@meiriyitie.com:~# mtr --report www.google.com HOST: localhost?????????????????? Loss%?? Snt?? Last?? Avg? Best? Wrst StDev1. 63.247.74.43????????????????? 0.0%??? 10??? 0.3?? 0.6?? 0.3?? 1.2?? 0.32. 63.247.64.157???????????????? 0.0%??? 10??? 0.4?? 1.0?? 0.4?? 6.1?? 1.83. 209.51.130.213??????????????? 0.0%??? 10??? 0.8?? 2.7?? 0.8? 19.0?? 5.74. aix.pr1.atl.google.com??????? 0.0%??? 10??? 6.7?? 6.8?? 6.7?? 6.9?? 0.15. 12.34.56.79?????????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.06. 12.34.56.78?????????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.07. 12.34.56.79?????????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.08. 12.34.56.78?????????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.09. 12.34.56.79?????????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.010. 12.34.56.78?????????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.011. 12.34.56.79?????????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.012. ????????????????????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.013. ????????????????????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.014. ????????????????????????????? 0.0%??? 10??? 0.0?? 0.0?? 0.0?? 0.0?? 0.0通過報告可以看打第4跳的路由器沒有正確配置。如果這種狀況發生了，您可以連接當地的網絡管理員或ISP解決問題。
ICMP 速率限制
ICMP 速率限制可引起數據包的丟失。如果數據包在這一跳有丟失，但是下面幾條都正常，我們可以判斷是 ICMP 速率限制的原因。如下：
root@meiriyitie.com:~# mtr --report www.google.comHOST: localhost?????????????????? Loss%?? Snt?? Last?? Avg? Best? Wrst StDev1. 63.247.74.43????????????????? 0.0%??? 10??? 0.3?? 0.6?? 0.3?? 1.2?? 0.32. 63.247.64.157???????????????? 0.0%??? 10??? 0.4?? 1.0?? 0.4?? 6.1?? 1.83. 209.51.130.213??????????????? 0.0%??? 10??? 0.8?? 2.7?? 0.8? 19.0?? 5.74. aix.pr1.atl.google.com??????? 0.0%??? 10??? 6.7?? 6.8?? 6.7?? 6.9?? 0.15. 72.14.233.56???????????????? 60.0%??? 10?? 27.2? 25.3? 23.1? 26.4?? 2.96. 209.85.254.247??????????????? 0.0%??? 10?? 39.1? 39.4? 39.1? 39.7?? 0.27. 64.233.174.46???????????????? 0.0%??? 10?? 39.6? 40.4? 39.4? 46.9?? 2.38. gw-in-f147.1e100.net????????? 0.0%??? 10?? 39.6? 40.5? 39.5? 46.7?? 2.2這種狀況是沒關系的。ICMP 速率限制是一種常見的手段，這樣可以減少網絡數據的負載，讓更重要的流量先通過。
超時
在很多種情況下會發生超時現象。例如：很多路由器可能會直接丟棄 ICMP 包，這時就會導致超時（???）。
另外，也有可能在數據返回的路上出現了問題。
超時不一定是數據包被丟失。如上例，數據包還是安全的到達目的地并且返回。中間節點的超時可能是路由器配置丟棄 ICMP 包，或者 QoS 設置引起的原因，這個是沒關系的。
根據您的 MTR 報告解決路由和網絡問題
MTR 報告顯示的路由問題大都是暫時性的。很多問題在24小時內都被解決了。大多數情況下，如果您發現了路由問題，ISP 提供商已經監視到并且正在解決中了。當您經歷網絡問題后，可以選擇提醒您的 ISP 提供商。當聯系您的提供商時，需要發送一下 MTR 報告和相關的數據。沒有有用的數據，提供商是沒有辦法去解決問題的。
然而大多數情況下，路由問題是比較少見的。比較常見的是因為物理距離太長，或者上網高峰，導致網絡變的很慢。尤其是跨越大西洋和太平洋的時候，網絡有時候會變的很慢。這種情況下，建議您選擇 VPS 的物理距離盡量接近您的目標客戶。
如果您遇到網絡連接問題，并且不能解讀 MTR 報告，您可以打開一個支持工單提交問題，Linode 工作人員會幫您分析報告。
更多信息：
您可以參考如下連接了解更多與 MTR 有關的知識。
The Official MTR Web Site
Understanding the Traceroute Command – Cisco Systems
Wikipedia article on traceroute
Traceroute by Exit109.com
譯者注：這篇文章實在是太長了，敲的我手都麻了。
轉載于:https://my.oschina.net/fdhay/blog/737477
總結
以上是生活随笔為你收集整理的使用 MTR 诊断网络问题的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 彻底弄懂css中单位px和em,rem的
- 下一篇： 让底部始终在浏览器底部