常用的 ping，tracert，nslookup 一般用來(lái)判斷主機的網(wǎng)絡(luò )連通性，其實(shí) Linux 下有一個(gè)更好用的網(wǎng)絡(luò )聯(lián)通性判斷工具，它可以結合ping nslookup tracert 來(lái)判斷網(wǎng)絡(luò )的相關(guān)特性，這個(gè)命令就是 mtr。mtr 全稱(chēng) my traceroute，是一個(gè)把 ping 和 traceroute 合并到一個(gè)程序的網(wǎng)絡(luò )診斷工具。

traceroute默認使用UDP數據包探測，而mtr默認使用ICMP報文探測，ICMP在某些路由節點(diǎn)的優(yōu)先級要比其他數據包低，所以測試得到的數據可能低于實(shí)際情況。

安裝方法 1.Windows系統可以直接在https://cdn.ipip.net/17mon/besttrace.exe下載BestTrace工具并安裝。也可以在https://github.com/oott123/WinMTR/releases GitHub上下載MTR專(zhuān)用工具，該工具為免安裝，下載后可以直接使用。

2.Linux可以直接運行命令進(jìn)行安裝。

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

3.Apple客戶(hù)端可以在A(yíng)pp store搜索Best NetTools下載安裝

4.Android客戶(hù)端：可以在Google Play上下載TracePing，但是由于國內Google Play無(wú)法訪(fǎng)問(wèn)，筆者自行下載下來(lái)，可以直接訪(fǎng)問(wèn) https://dwz.cn/KCdNPH4c 下載TracePing。

使用

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

mtr qq.com

MTR qq.com 測試界面

具體輸出的參數含義為：

• 第一列是IP地址

• 丟包率：Loss

• 已發(fā)送的包數：Snt

• 最后一個(gè)包的延時(shí)：Last

• 平均延時(shí)：Avg

• 最低延時(shí)：Best

• 最差延時(shí)：Wrst

• 方差（穩定性）：StDev

參數說(shuō)明

-r or --report

使用 mtr -r qq.com 來(lái)打印報告，如果不使用 -r or --report 參數 mtr 會(huì )不斷動(dòng)態(tài)運行。使用 report 選項， mtr 會(huì )向 qq.com 主機發(fā)送 10 個(gè) ICMP 包，然后直接輸出結果。通常情況下 mtr 需要幾秒鐘時(shí)間來(lái)輸出報告。mtr 報告由一系列跳數組成，每一跳意味著(zhù)數據包通過(guò)節點(diǎn)或者路由器來(lái)達到目的主機。

一般情況下 mtr 前幾跳都是本地 ISP，后幾跳屬于服務(wù)商比如 騰訊數據中心，中間跳數則是中間節點(diǎn)，如果發(fā)現前幾跳異常，需要聯(lián)系本地 ISP 服務(wù)提供上，相反如果后幾跳出現問(wèn)題，則需要聯(lián)系服務(wù)提供商，中間幾跳出現問(wèn)題，則需要聯(lián)系運營(yíng)商進(jìn)行處理

默認使用 -r 參數來(lái)生成報告，只會(huì )發(fā)送10個(gè)數據包，如果想要自定義數據包數量，可以使用 -c 參數

-s or --packetsize

使用 -s 來(lái)指定ping數據包的大小

mtr -s 100 qq.com

100 bytes 數據包會(huì )用來(lái)發(fā)送，測試，如果設置為負數，則每一次發(fā)送的數據包的大小都會(huì )是一個(gè)隨機數。

-c

指定發(fā)送數量

mtr -c 100 qq.com

-n

不進(jìn)行主機解釋

使用 -n 選項來(lái)讓 mtr 只輸出 IP，而不對主機 host name 進(jìn)行解釋

mtr -n qq.com

MTR結果分析

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

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

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

例如，如果標準偏差很大，說(shuō)明數據包的延遲是不確定的。一些數據包延遲很?。ɡ纾?5ms），另一些數據包延遲很大（例如：350ms）。當10個(gè)數據包全部發(fā)出后，得到的平均延遲可能是正常的，但是平均延遲是不能很好的反應實(shí)際情況的。如果標準偏差很高，使用最好和最壞的延遲來(lái)確定平均延遲是一個(gè)較好的方案。

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

當分析 MTR 的輸出時(shí)，您需要注意兩點(diǎn)：loss 和 latency。

網(wǎng)絡(luò )丟包

如果在任何一跳上看到 loss 的百分比，這就說(shuō)明這一跳上可能有問(wèn)題了。當然，很多服務(wù)提供商人為限制 ICMP 發(fā)送的速率，這也會(huì )導致此問(wèn)題。那么如何才能指定是人為的限制 ICMP 傳輸 還是確定有丟包的現象？此時(shí)需要查看下一跳。如果下一跳沒(méi)有丟包現象，說(shuō)明上一條是人為限制的。如下示例：

人為限制MTR丟包

在此例中，第4跳發(fā)生了丟包現象，但是接下來(lái)幾條都沒(méi)任何丟包現象，說(shuō)明第二跳的丟包是人為限制的。如果在接下來(lái)的幾條中都有丟包，那就可能是第二跳有問(wèn)題了。請記住，ICMP 包的速率限制和丟失可能會(huì )同時(shí)發(fā)生。

MTR丟包截圖

從上面的圖中，您可以看從第13跳和第17跳都有 10% 的丟包率，從接下來(lái)的幾跳都有丟包現象，但是最后15,16跳都是100%的丟包率，我們可以猜測到100%的丟包率除了網(wǎng)絡(luò )糟糕的原因之前還有人為限制 ICMP。所以，當我們看到不同的丟包率時(shí)，通常要以最后幾跳為準。

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

此外，互聯(lián)網(wǎng)設施的維護或短暫的網(wǎng)絡(luò )擁擠可能會(huì )帶來(lái)短暫的丟包率，當出現短暫的10%丟包率時(shí)候，不必擔心，應用層的程序會(huì )彌補這點(diǎn)損失。

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

除了可以通過(guò)MTR報告查看丟包率，我們也還可以看到本地到目的之間的時(shí)延。因為是不通的位置，延遲通常會(huì )隨著(zhù)條數的增加而增加。所以，延遲通常取決于節點(diǎn)之間的物理距離和線(xiàn)路質(zhì)量。

MTR查看網(wǎng)絡(luò )延遲

從上面的MTR報告截圖中，我們可以看到從第11跳到12跳的延遲猛增，直接導致了后面的延遲也很大，一般有可能是11跳到12跳屬于不通地域，物理距離導致時(shí)延猛增，也有可能是第12條的路由器配置不當，或者是線(xiàn)路擁塞。需要具體問(wèn)題進(jìn)行具體的分析。然而，高延遲并不一定意味著(zhù)當前路由器有問(wèn)題。延遲很大的原因也有可能是在返回過(guò)程中引發(fā)的。從這份報告的截圖看不到返回的路徑，返回的路徑可能是完全不同的線(xiàn)路，所以一般需要進(jìn)行雙向MTR測試。

注：ICMP 速率限制也可能會(huì )增加延遲，但是一般可以查看最后一條的時(shí)間延遲來(lái)判斷是否是上述情況。

根據MTR結果解決網(wǎng)絡(luò )問(wèn)題

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

然而大多數情況下，路由問(wèn)題是比較少見(jiàn)的。比較常見(jiàn)的是因為物理距離太長(cháng)，或者上網(wǎng)高峰，導致網(wǎng)絡(luò )變的很慢。尤其是跨越大西洋和太平洋的時(shí)候，網(wǎng)絡(luò )有時(shí)候會(huì )變的很慢。這種情況下，建議就近接入客戶(hù)的節點(diǎn)。