當(dāng)前位置：首頁 >

使用 MTR 诊断网络问题

發(fā)布時(shí)間：2025/7/14 51 豆豆

生活随笔收集整理的這篇文章主要介紹了使用 MTR 诊断网络问题小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

為什么80%的碼農(nóng)都做不了架構(gòu)師？>>> ??

使用 MTR 診斷網(wǎng)絡(luò)問題

每日一貼???2015年5月26日???3 條評(píng)論

MTR 是一款強(qiáng)大的網(wǎng)絡(luò)診斷工具，網(wǎng)絡(luò)管理員使用 MTR 可以診斷和隔離網(wǎng)絡(luò)問題，并且為上游 ISP 提供有用的網(wǎng)絡(luò)狀態(tài)報(bào)告。

MTR 是傳統(tǒng) traceroute 命令的進(jìn)化版，并且可以提供強(qiáng)大的數(shù)據(jù)樣本，因?yàn)樗狭?traceroute 和 ping 這兩個(gè)命令的精華。本文帶您深入了解 MTR ，從數(shù)據(jù)如何生成，到如果正確理解報(bào)告樣本并得出相應(yīng)的結(jié)論。

關(guān)于網(wǎng)絡(luò)診斷技術(shù)的基本理論請(qǐng)參考?network diagnostics?.如果您懷疑您的 Linux 系統(tǒng)有其他問題，請(qǐng)參考system diagnostics?。最后，我們假定您已經(jīng)掌握了?getting started guide?(入門指南) 。

網(wǎng)絡(luò)診斷相關(guān)的背景知識(shí)

網(wǎng)絡(luò)診斷工具例如 ping traceroute mtr 都使用的 “ICMP” 包來測(cè)試 Internet 兩點(diǎn)之間的網(wǎng)絡(luò)連接狀況。當(dāng)用戶使用 ping 命令 ping 網(wǎng)絡(luò)上的主機(jī)后， ICMP 包將會(huì)發(fā)送到目的主機(jī)，然后在目的主機(jī)返回響應(yīng)。這樣，就可以得知本機(jī)到目的主機(jī) ICMP 包傳輸所使用的往返時(shí)間。

相對(duì)于其他命令僅僅收集傳輸路徑或響應(yīng)時(shí)間，MTR 工具會(huì)收集更多的信息，比如連接狀態(tài)，連接可用性，以及傳輸路徑中主機(jī)的響應(yīng)性。由于這些額外的信息，我們建議您盡可能完整的展現(xiàn) Internet 兩個(gè)主機(jī)之間的網(wǎng)絡(luò)連接信息。接下來我們講述如何安裝 MTR 軟件，以及如何看懂這款軟件的輸出結(jié)果。

安裝 MTR

在 Debian 和 Ubuntu 系統(tǒng)中，使用如下命令更新系統(tǒng)，然后安裝 MTR：

apt-get update apt-get upgrade apt-get install mtr-tiny

在 CentOS 和 Fedora 系統(tǒng)中，使用如下命令更新系統(tǒng)，并安裝 MTR：

yum update yum install mtr

在 Arch Linux 系統(tǒng)中，按照如下命令更新系統(tǒng)并安裝 MTR：

pacman -Sy pacman -S mtr

如果您的本機(jī)使用的是 Linux 系統(tǒng)，并且想用 MTR 測(cè)試網(wǎng)絡(luò)狀況，請(qǐng)按照如上教程安裝。

如果您的本機(jī)使用的 Mac OS X 系統(tǒng)，可以使用?Homebre?或?MacPorts?來安裝 MTR。使用 Homebrew 安裝 MTR：

brew install mtr

使用 MacPorts 安裝 MTR：

port install mtr

如果您的本機(jī)使用的是 Windows 系統(tǒng)，您可以使用 “WinMTR”。可以從這里下載：WinMTR?.

因?yàn)?MTR 提供兩個(gè)主機(jī)之間的網(wǎng)絡(luò)路徑圖，您可以把它想象成一款定向工具。另外，因?yàn)榈刂肺恢没蛏嫌蜪SP路由器的原因，路徑有時(shí)候可能會(huì)有很大的不同。所以我們建議您盡可能多的收集 MTR 的報(bào)告信息。

如果您遇到網(wǎng)絡(luò)方面的問題， Linode 的技術(shù)支持經(jīng)常建議您收集雙向的 MTR 報(bào)告（從 Linode 出發(fā)和到 Linode 的往返路徑）。這是因?yàn)橛袝r(shí)候網(wǎng)絡(luò)狀況從一個(gè)方向不會(huì)出現(xiàn)錯(cuò)誤，但是從另一個(gè)方向會(huì)出現(xiàn)丟包現(xiàn)象。當(dāng)出現(xiàn)網(wǎng)絡(luò)問題時(shí)候，雙向 MTR 報(bào)告是十分有用的。

在本文中，運(yùn)行 mtr 命令的主機(jī)稱為源主機(jī)，被查詢的主機(jī)稱為目的主機(jī)。

在 Unix-based 系統(tǒng)中使用 MTR

當(dāng)在Linux 或 Mac OS X 系統(tǒng)中安裝 MTR 后，您可以使用如下命令來產(chǎn)生 MTR 報(bào)告：

mtr -rw [destination_host]

例如，我們需要測(cè)試到 example.com 的路由信息和網(wǎng)絡(luò)連接質(zhì)量，在源主機(jī)上運(yùn)行如下命令：

mtr -rw example.com

如果我們遇到網(wǎng)絡(luò)問題，需要聯(lián)系 Linode 的技術(shù)支持，Linode 需要我們提供雙向的 MTR 報(bào)告。第一份是從您的本機(jī)到 Linode VPS 的 MTR 報(bào)告，命令如下：

mtr -rw 87.65.43.21

使用您的Linode VPS 的IP地址替換 87.65.43.21 。

然后我們需要搜集從您的Linode VPS 返回到您的本機(jī)的 MTR 報(bào)告，命令如下：

mtr -rw 12.34.56.78

請(qǐng)使用您的本地公網(wǎng)IP地址替換 12.34.56.78 。如果您不確定您的本地公網(wǎng)IP地址，您可以使用相關(guān)的第三方服務(wù)，如果 WhatIsMyIP.com。（譯者著：國(guó)內(nèi)可以使用 ip.c、ip138.com 、ipip.net 等第三方服務(wù)）

注

我們使用 rw 參數(shù)是為了方便讓 Linode 的技術(shù)支持看到更多的網(wǎng)絡(luò)信息。

r 產(chǎn)生報(bào)告信息（–report 的縮寫）

w 報(bào)告中帶有 hostname 信息，Linode 技術(shù)支持可以看到每一跳的完整 hostname （–report-wide 的縮寫）

在 Windows 系統(tǒng)下使用 MTR

首先，Windows 下的 MTR 有 GUI 的，運(yùn)行 WinMTR，輸入目的地址，然后選擇開始即可，您就會(huì)看到輸出內(nèi)容。

另外，您還需要使用 Linux 版本的 MTR 來產(chǎn)生從 Linode 到您本地的返回線路網(wǎng)絡(luò)狀況。（因?yàn)槟壳?Linode 僅有Linux 的VPS，哈哈）

如何讀懂 MTR 報(bào)告

因?yàn)?MTR 報(bào)告包括了豐富的信息，新手第一次閱讀有點(diǎn)困難。下面是我本地到 google.com 的測(cè)試報(bào)告：

$ 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 命令來輸出這篇報(bào)告。使用 report 選項(xiàng)可以給 google.com 主機(jī)發(fā)送10個(gè) ICMP 包，然后輸出報(bào)告。如果我們不使用 –report 參數(shù)， mtr 會(huì)不斷的動(dòng)態(tài)運(yùn)行。在動(dòng)態(tài)模式下， mtr 的輸出結(jié)果表述每個(gè)主機(jī)的往返時(shí)間。大多數(shù)情況下，使用 –report 參數(shù)就可以提供足夠的數(shù)據(jù)了。

在命令下面，就是 MTR 產(chǎn)生的輸出報(bào)告。在通常情況下， MTR需要幾秒鐘的時(shí)間來輸出報(bào)告，但是偶爾可能需要更長(zhǎng)的時(shí)間。MTR 報(bào)告是由一系列跳數(shù)組成的（在上述例子中是12跳）。“跳”意味著節(jié)點(diǎn)，或路由器，數(shù)據(jù)包通過它們才能到達(dá)目的主機(jī)。在上面例子中，數(shù)據(jù)包經(jīng)過本地網(wǎng)絡(luò)的“內(nèi)層”和“外層”，然后到達(dá) “68.85.118.13”，然后再到一系列的域名主機(jī)。主機(jī)的域名是通過反向 DNS 查找確定的。如果您想忽略 rDNS 查找，您可以使用 –no-dns 參數(shù)，使用 –no-dns 參數(shù)后，報(bào)告結(jié)果如下：

%? 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

當(dāng)我們研究 MTR 報(bào)告時(shí)候，最好找出每一跳的任何問題。除了可以查看兩個(gè)服務(wù)器之間的路徑之外，MTR 在它的七列數(shù)據(jù)中提供了很多有價(jià)值的數(shù)據(jù)統(tǒng)計(jì)報(bào)告。 Loss% 列展示了數(shù)據(jù)包在每一跳的丟失率。 Snt 列記錄的多少個(gè)數(shù)據(jù)包被送出。使用 –report 參數(shù)默認(rèn)會(huì)送出10個(gè)數(shù)據(jù)包。如果使用 –report-cycles=[number-of-packets] 選項(xiàng)，MTR 就會(huì)按照 [number-of-packets] 指定的數(shù)量發(fā)出 ICMP 數(shù)據(jù)包。

Last, Avg, Best 和 Wrst 列都標(biāo)識(shí)數(shù)據(jù)包往返的時(shí)間，使用的是毫秒（ ms ）單位表示。 Last 表示最后一個(gè)數(shù)據(jù)包所用的時(shí)間， Avg 表示評(píng)價(jià)時(shí)間， Best 和 Wrst 表示最小和最大時(shí)間。在大多數(shù)情況下，平均時(shí)間（ Avg）列需要我們特別注意。

最后一列 StDev 提供了數(shù)據(jù)包在每個(gè)主機(jī)的標(biāo)準(zhǔn)偏差。如果標(biāo)準(zhǔn)偏差越高，說明數(shù)據(jù)包在這個(gè)節(jié)點(diǎn)的延時(shí)越不相同。標(biāo)準(zhǔn)偏差會(huì)讓您了解到平均延時(shí)是否是真的延時(shí)時(shí)間的中心點(diǎn)，或者測(cè)量數(shù)據(jù)受到某些問題的干擾。

例如，如果標(biāo)準(zhǔn)偏差很大，說明數(shù)據(jù)包的延遲是不確定的。一些數(shù)據(jù)包延遲很小（例如：25ms），另一些數(shù)據(jù)包延遲很大（例如：350ms）。當(dāng)10個(gè)數(shù)據(jù)包全部發(fā)出后，得到的平均延遲可能是正常的，但是平均延遲是不能很好的反應(yīng)實(shí)際情況的。如果標(biāo)準(zhǔn)偏差很高，使用最好和最壞的延遲來確定平均延遲是一個(gè)較好的方案。

在大多數(shù)情況下，您可以把 MTR 的輸出分成三大塊。根據(jù)配置，第二或第三跳一般都是您的本地 ISP，倒數(shù)第二或第三跳一般為您目的主機(jī)的ISP。中間的節(jié)點(diǎn)是數(shù)據(jù)包經(jīng)過的路由器。

例如，我們?cè)诒镜仉娔X運(yùn)行 MTR，目的地是您的 Linode VPS，一般前三跳屬于您的本地 ISP，后三跳屬于 Linode 數(shù)據(jù)中心這邊的。中間的條數(shù)是屬于中間節(jié)點(diǎn)的。當(dāng)您在本地運(yùn)行 MTR，如果您在前幾跳發(fā)現(xiàn)異常，請(qǐng)聯(lián)系您本地的 ISP 服務(wù)提供商。相反，如果您在接近目的地的幾跳發(fā)現(xiàn)問題，請(qǐng)聯(lián)系您目的地的服務(wù)器提供商（例如：Linode）。如果您的問題出現(xiàn)在中間幾跳，很不幸，兩邊的服務(wù)提供商的能力有限，可能不能完全為您解決問題嘍。

分析 MTR 報(bào)告

核查數(shù)據(jù)包的丟失

當(dāng)分析 MTR 的輸出時(shí)，您需要注意兩點(diǎn)： loss 和 latency。首先，讓我們討論一下 loss。如果您在任何一跳上看到 loss 的百分比，這就說明這一跳上可能有問題了。當(dāng)然，很多服務(wù)提供商人為限制 ICMP 發(fā)送的速率，這也會(huì)導(dǎo)致此問題。那么如何才能指定是人為的限制 ICMP 傳輸還是確定有丟包的現(xiàn)象？我們需要查看下一跳。如果下一跳沒有丟包現(xiàn)象，說明上一條是人為限制的。如下示例：

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

在此例中，第二跳發(fā)生了丟包現(xiàn)象，但是接下來幾條都沒任何丟包現(xiàn)象，說明第二跳的丟包是人為限制的。如果在接下來的幾條中都有丟包，那就可能是第二跳有問題了。請(qǐng)記住，ICMP 包的速率限制和丟失可能會(huì)同時(shí)發(fā)生。如果發(fā)生包的丟失情況，我們要用最低百分比來衡量時(shí)間情況。為什么這么說呢？請(qǐng)看如下示例：

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

在這個(gè)例子中，您可以看打第3跳和第4跳都有 60% 的丟包率，從接下來的幾跳都有丟包現(xiàn)象，所以不像是人為限制 ICMP 速率的原因。但是最后幾跳都是40%的丟包率，我們可以猜測(cè)到60%的丟包率除了網(wǎng)絡(luò)糟糕的原因之前還有人為限制 ICMP。所以，當(dāng)我們看到不同的丟包率時(shí)，通常要以最后幾跳為準(zhǔn)。

還有很多時(shí)候問題是在數(shù)據(jù)包返回途中發(fā)生的。數(shù)據(jù)包可以成功的到達(dá)目的主機(jī)，但是返回過程中遇到“困難”了。所以，當(dāng)問題發(fā)生后，我們通常需要收集反方向的 MTR 報(bào)告。

此外，互聯(lián)網(wǎng)設(shè)施的維護(hù)或短暫的網(wǎng)絡(luò)擁擠可能會(huì)帶來短暫的丟包率，當(dāng)出現(xiàn)短暫的10%丟包率時(shí)候，不必?fù)?dān)心，應(yīng)用層的程序會(huì)彌補(bǔ)這點(diǎn)損失。

讀懂網(wǎng)絡(luò)延遲

除了可以通過 MTR 報(bào)告看到丟包率，我們還可以看到本地到目的主機(jī)之間的延時(shí)。因?yàn)椴煌奈锢砦恢?#xff0c;延遲通常隨著跳數(shù)的增加而增加。所以，延遲通常取決于節(jié)點(diǎn)之間的物理距離和線路質(zhì)量。

例如，在同樣的傳輸距離下，dial-up連接比cable modem連接有更大的延遲。如下示例中顯示 MTR 報(bào)告：

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

在這份報(bào)告中，從第三跳到第四跳的延遲猛增，直接導(dǎo)致了后面的延遲也很大。這可能是因?yàn)榈谒奶穆酚善髋渲貌划?dāng)，或者線路很擁堵的原因。

然而，高延遲并不一定意味著當(dāng)前路由器有問題。這份報(bào)告雖然看到第四跳有點(diǎn)問題，但是數(shù)據(jù)仍然可以正常達(dá)到目的主機(jī)并且返回給主機(jī)。延遲很大的原因也有可能是在返回過程中引發(fā)的。我這份報(bào)告我們看不到返回的路徑，返回的路徑可能是完全不同的線路，所以我們一般要進(jìn)行雙向測(cè)試了。

ICMP 速率限制也可能會(huì)增加延遲，如下：

乍一看，第4跳和第5跳直接的延遲很大。但是第5跳之后，延遲又恢復(fù)正常了。最后的延遲差不多為 40ms。像這種情況，是不影響實(shí)際情況的。因?yàn)榭赡軆H僅是第5跳設(shè)備限制了 ICMP 傳輸速率的原因。所以我們一般要用最后一跳的實(shí)際延遲為準(zhǔn)。

常見的 MTR 報(bào)告類型

很多網(wǎng)絡(luò)問題十分麻煩，并且需要上級(jí)網(wǎng)絡(luò)提供商來幫助。然而，這里有很多常見的 MTR 報(bào)告所描述的網(wǎng)絡(luò)問題。如果您正在經(jīng)歷一些網(wǎng)絡(luò)問題，并且想診斷出原因，可以參考如下示例：

目的主機(jī)網(wǎng)絡(luò)配置不當(dāng)

在下面這個(gè)例子中，數(shù)據(jù)包在目的地出現(xiàn)了 100% 的丟包。乍一看是數(shù)據(jù)包沒有到達(dá)，其實(shí)未必，很有可能是路由器或主機(jī)配置不當(dāng)。

MTR 報(bào)告數(shù)據(jù)包沒有到達(dá)目的主機(jī)是因?yàn)槟康闹鳈C(jī)沒有發(fā)送任何應(yīng)答。這可能是目的主機(jī)防火墻的原因，例如： iptables 配置丟掉 ICMP 包所致。

家庭或辦公室路由器的原因

有時(shí)候家庭路由器的原因?qū)е?MTR 報(bào)告看起來有點(diǎn)誤導(dǎo)。

% 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% 的丟包率所嚇到，這并不表明這里有問題。你可以看打在接下來幾跳是沒有任何丟包的。

運(yùn)營(yíng)商的路由器沒有正確配置

有時(shí)候您的運(yùn)營(yíng)商的路由器配置原因，導(dǎo)致 ICMP 包永遠(yuǎn)不能到達(dá)目的地，例如：

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

當(dāng)沒有額外的路由信息時(shí)，將會(huì)顯示問號(hào)（???），下面例子也一樣：

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

有時(shí)候，一個(gè)錯(cuò)誤配置的路由器，將會(huì)在一個(gè)環(huán)路中不斷發(fā)送數(shù)據(jù)包，如下：

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

通過報(bào)告可以看打第4跳的路由器沒有正確配置。如果這種狀況發(fā)生了，您可以連接當(dāng)?shù)氐木W(wǎng)絡(luò)管理員或ISP解決問題。

ICMP 速率限制

ICMP 速率限制可引起數(shù)據(jù)包的丟失。如果數(shù)據(jù)包在這一跳有丟失，但是下面幾條都正常，我們可以判斷是 ICMP 速率限制的原因。如下：

這種狀況是沒關(guān)系的。ICMP 速率限制是一種常見的手段，這樣可以減少網(wǎng)絡(luò)數(shù)據(jù)的負(fù)載，讓更重要的流量先通過。

超時(shí)

在很多種情況下會(huì)發(fā)生超時(shí)現(xiàn)象。例如：很多路由器可能會(huì)直接丟棄 ICMP 包，這時(shí)就會(huì)導(dǎo)致超時(shí)（???）。
另外，也有可能在數(shù)據(jù)返回的路上出現(xiàn)了問題。

超時(shí)不一定是數(shù)據(jù)包被丟失。如上例，數(shù)據(jù)包還是安全的到達(dá)目的地并且返回。中間節(jié)點(diǎn)的超時(shí)可能是路由器配置丟棄 ICMP 包，或者 QoS 設(shè)置引起的原因，這個(gè)是沒關(guān)系的。

根據(jù)您的 MTR 報(bào)告解決路由和網(wǎng)絡(luò)問題

MTR 報(bào)告顯示的路由問題大都是暫時(shí)性的。很多問題在24小時(shí)內(nèi)都被解決了。大多數(shù)情況下，如果您發(fā)現(xiàn)了路由問題，ISP 提供商已經(jīng)監(jiān)視到并且正在解決中了。當(dāng)您經(jīng)歷網(wǎng)絡(luò)問題后，可以選擇提醒您的 ISP 提供商。當(dāng)聯(lián)系您的提供商時(shí)，需要發(fā)送一下 MTR 報(bào)告和相關(guān)的數(shù)據(jù)。沒有有用的數(shù)據(jù)，提供商是沒有辦法去解決問題的。

然而大多數(shù)情況下，路由問題是比較少見的。比較常見的是因?yàn)槲锢砭嚯x太長(zhǎng)，或者上網(wǎng)高峰，導(dǎo)致網(wǎng)絡(luò)變的很慢。尤其是跨越大西洋和太平洋的時(shí)候，網(wǎng)絡(luò)有時(shí)候會(huì)變的很慢。這種情況下，建議您選擇 VPS 的物理距離盡量接近您的目標(biāo)客戶。

如果您遇到網(wǎng)絡(luò)連接問題，并且不能解讀 MTR 報(bào)告，您可以打開一個(gè)支持工單提交問題，Linode 工作人員會(huì)幫您分析報(bào)告。

總結(jié)

以上是生活随笔為你收集整理的使用 MTR 诊断网络问题的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。

网络
mtr

上一篇：彻底弄懂css中单位px和em,rem的
下一篇： Django 模型

日韩av黄I国产麻豆传媒I国产91av视频在线观看I日韩一区二区三区在线看I美女国产在线I麻豆视频国产在线观看I成人黄色短片

生活随笔