使用 MTR 診斷網絡問題
使用 MTR 診斷網絡問題
MTR 是一款強大的網絡診斷工具，網絡管理員使用 MTR 能夠診斷和隔離網絡問題，而且爲上游 ISP 提供有用的網絡狀態報告。node
MTR 是傳統 traceroute 命令的進化版，而且能夠提供強大的數據樣本，由於他集合了 traceroute 和 ping 這兩個命令的精華。本文帶您深刻了解 MTR ，從數據如何生成，到若是正確理解報告樣本並得出相應的結論。linux
關於網絡診斷技術的基本理論請參考 network diagnostics .若是您懷疑您的 Linux 系統有其餘問題，請參考system diagnostics 。最後，咱們假定您已經掌握了 getting started guide (入門指南) 。ios
網絡診斷相關的背景知識
網絡診斷工具 例如 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：ide
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 StDev 1. inner-cake 0.0% 10 2.8 2.1 1.9 2.8 0.3 2. outer-cake 0.0% 10 3.2 2.6 2.4 3.2 0.3 3. 68.85.118.13 0.0% 10 9.8 12.2 8.7 18.2 3.0 4. po-20-ar01.absecon.nj.panjde 0.0% 10 10.2 10.4 8.9 14.2 1.6 5. be-30-crs01.audubon.nj.panjd 0.0% 10 10.8 12.2 10.1 16.6 1.7 6. pos-0-12-0-0-ar01.plainfield 0.0% 10 13.4 14.6 12.6 21.6 2.6 7. pos-0-6-0-0-cr01.newyork.ny. 0.0% 10 15.2 15.3 13.9 18.2 1.3 8. pos-0-4-0-0-pe01.111eighthav 0.0% 10 16.5 16.2 14.5 19.3 1.3 9. as15169-3.111eighthave.ny.ib 0.0% 10 16.0 17.1 14.2 27.7 3.9 10. 72.14.238.232 0.0% 10 19.1 22.0 13.9 43.3 11.1 11. 209.85.241.148 0.0% 10 15.1 16.2 14.8 20.2 1.6 12. 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 StDev 1. 192.168.1.1 0.0% 10 2.2 2.2 2.0 2.7 0.2 2. 68.85.118.13 0.0% 10 8.6 11.0 8.4 17.8 3.0 3. 68.86.210.126 0.0% 10 9.1 12.1 8.5 24.3 5.2 4. 68.86.208.22 0.0% 10 12.2 15.1 11.7 23.4 4.4 5. 68.85.192.86 0.0% 10 17.2 14.8 13.2 17.2 1.3 6. 68.86.90.25 0.0% 10 14.2 16.4 14.2 20.3 1.9 7. 68.86.86.194 0.0% 10 17.6 16.8 15.5 18.1 0.9 8. 75.149.230.194 0.0% 10 15.0 20.1 15.0 33.8 5.6 9. 72.14.238.232 0.0% 10 15.6 18.7 14.1 32.8 5.9 10. 209.85.241.148 0.0% 10 16.3 16.9 14.7 21.2 2.2 11. 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 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 6.7 6.8 6.7 6.9 0.1 5. 72.14.233.56 0.0% 10 254.2 250.3 230.1 263.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
乍一看，第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 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 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 100.0 10 0.0 0.0 0.0 0.0 0.0
MTR 報告數據包沒有到達目的主機是由於目的主機沒有發送任何應答。這多是目的主機防火牆的緣由，例如： iptables 配置丟掉 ICMP 包所致。
家庭或辦公室路由器的緣由
有時候家庭路由器的緣由致使 MTR 報告看起來有點誤導。
% mtr --no-dns --report google.com HOST: deleuze Loss% Snt Last Avg Best Wrst StDev 1. 192.168.1.1 0.0% 10 2.2 2.2 2.0 2.7 0.2 2. ??? 100.0 10 8.6 11.0 8.4 17.8 3.0 3. 68.86.210.126 0.0% 10 9.1 12.1 8.5 24.3 5.2 4. 68.86.208.22 0.0% 10 12.2 15.1 11.7 23.4 4.4 5. 68.85.192.86 0.0% 10 17.2 14.8 13.2 17.2 1.3 6. 68.86.90.25 0.0% 10 14.2 16.4 14.2 20.3 1.9 7. 68.86.86.194 0.0% 10 17.6 16.8 15.5 18.1 0.9 8. 75.149.230.194 0.0% 10 15.0 20.1 15.0 33.8 5.6 9. 72.14.238.232 0.0% 10 15.6 18.7 14.1 32.8 5.9 10. 209.85.241.148 0.0% 10 16.3 16.9 14.7 21.2 2.2 11. 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 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 6.7 6.8 6.7 6.9 0.1 5. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 6. ??? 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.0 8. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 9. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 10. ??? 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 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 6.7 6.8 6.7 6.9 0.1 5. 172.16.29.45 0.0% 10 0.0 0.0 0.0 0.0 0.0 6. ??? 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.0 8. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 9. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 10. ??? 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 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 6.7 6.8 6.7 6.9 0.1 5. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0 6. 12.34.56.78 0.0% 10 0.0 0.0 0.0 0.0 0.0 7. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0 8. 12.34.56.78 0.0% 10 0.0 0.0 0.0 0.0 0.0 9. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0 10. 12.34.56.78 0.0% 10 0.0 0.0 0.0 0.0 0.0 11. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0 12. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 13. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 14. ??? 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.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 6.7 6.8 6.7 6.9 0.1 5. 72.14.233.56 60.0% 10 27.2 25.3 23.1 26.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 速率限制是一種常見的手段，這樣能夠減小網絡數據的負載，讓更重要的流量先經過。
超時
在不少種狀況下會發生超時現象。例如：不少路由器可能會直接丟棄 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 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. ??? 0.0% 10 7.2 8.3 7.1 16.4 2.9 6. ??? 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 包，或者 QoS 設置引發的緣由，這個是不要緊的。
根據您的 MTR 報告解決路由和網絡問題
MTR 報告顯示的路由問題大都是暫時性的。不少問題在24小時內都被解決了。大多數狀況下，若是您發現了路由問題，ISP 提供商已經監視到而且正在解決中了。當您經歷網絡問題後，能夠選擇提醒您的 ISP 提供商。當聯繫您的提供商時，須要發送一下 MTR 報告和相關的數據。沒有有用的數據，提供商是沒有辦法去解決問題的。
然而大多數狀況下，路由問題是比較少見的。比較常見的是由於物理距離太長，或者上網高峯，致使網絡變的很慢。尤爲是跨越大西洋和太平洋的時候，網絡有時候會變的很慢。這種狀況下，建議您選擇 VPS 的物理距離儘可能接近您的目標客戶。
若是您遇到網絡鏈接問題，而且不能解讀 MTR 報告，您能夠打開一個支持工單提交問題，Linode 工做人員會幫您分析報告。
更多信息：
您能夠參考以下鏈接瞭解更多與 MTR 有關的知識。
Understanding the Traceroute Command – Cisco Systems
Wikipedia article on traceroute
譯者注：這篇文章實在是太長了，敲的我手都麻了。
- 1. 用MTR診斷網絡問題
- 2. MTR診斷網絡
- 3. MTR 網絡診斷工具
- 4. 用Strace診斷問題
- 5. 使用PerfView診斷.Net GC的問題
- 6. GC問題診斷
- 7. 你知道ping和traceroute，但你知道mtr網絡診斷工具麼？
- 8. 網絡故障診斷
- 9. curl http網絡診斷
- 10. 網絡診斷 網絡連接配置
- 更多相關文章...
- • TCP/IP網絡訪問層的構成 - TCP/IP教程
- • 使用UDP協議檢測網絡性能 - TCP/IP教程
- • Composer 安裝與使用
- • PHP Ajax 跨域問題最佳解決方案
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 用MTR診斷網絡問題
- 2. MTR診斷網絡
- 3. MTR 網絡診斷工具
- 4. 用Strace診斷問題
- 5. 使用PerfView診斷.Net GC的問題
- 6. GC問題診斷
- 7. 你知道ping和traceroute，但你知道mtr網絡診斷工具麼？
- 8. 網絡故障診斷
- 9. curl http網絡診斷
- 10. 網絡診斷 網絡連接配置