參考資料：
mtr的man手冊
簡介
MTR的名稱來源是My TraceRoute，原來源是Matt's TraceRoute。mtr是一個網絡診斷工具，將ping和traceroute命令的功能合二爲一。
命令ping着重查看到目標節點的延遲。
# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=2 ttl=106 time=245 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=106 time=245 ms ... ...
命令traceroute可以查看數據包經過的每一個節點（或者說每一跳（hop））的信息。
# traceroute -n 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 192.168.1.1 1.229 ms 1.143 ms 1.055 ms 2 117.30.114.1 133.626 ms 133.606 ms 134.264 ms ... ... 12 108.170.237.45 252.366 ms 209.85.252.245 282.760 ms 209.85.240.31 282.729 ms 13 8.8.8.8 241.518 ms 241.971 ms 250.866 ms
對於數據包從源到目的地所經過的每個節點，mtr都會記住。而後向這些節點發送ICMP數據包，通過ICMP響應數據包來獲取這些節點的網絡信息（如延遲、丟包率等）。大多數情況下mtr檢測網絡信息時使用的數據包是ICMP數據包，不過也可以是TCP或者UDP數據包。
我們可以鍵入以下命令嘗試執行。
注意：我自己使用Vmware Workstation Pro 15.5構建虛擬機時，如果虛擬機的網絡是NAT模式的話，那麼mtr追蹤百度，出來的結果就很少，只有短短一兩行。切換成橋接模式才正常。有知道如何解決這個疑難雜症的朋友們，望不吝賜教！
# mtr -n www.baidu.com
得到的結果如下，全屏會被替換成mtr的輸出結果，默認情況下每隔1秒mtr就會發送ICMP數據包去探測網絡情況，因此界面每隔1秒就會刷新1次。
在這個界面下我們可以鍵入各種命令來與mtr結果進行交互，例如p是暫停，空格是繼續等。像這種用戶可以鍵入命令與之交互的模式/界面，一般是基於curses（一種終端控制庫）的文本界面（TUI）。
接下來我們將圍繞命令的選項、與命令結果的交互命令以及如何解析mtr結果展開討論。
命令的選項
操作系統和軟件版本：
# lsb_release -d Description: CentOS Linux release 7.5.1804 (Core) # mtr --version mtr 0.85
man手冊中的語法比較冗雜，因爲它把短選項和長選項都列出來了。
mtr [-BfhvrctglxspQemniuTP46] [--help] [--version] [--report] [--report-wide] [--report-cycles COUNT] [--curses] [--split] [--raw] [ --xml] [--mpls] [--no-dns] [--show-ips] [--gtk] [--address IP.ADD.RE.SS] [--interval SECONDS] [--max- ttl NUM] [--first-ttl NUM] [--bitpattern NUM] [--tos NUM] [--psize BYTES | -s BYTES] [--tcp] [--udp] [--port PORT] [--timeout SECONDS] HOSTNAME [PACKETSIZE]
我們可以大致簡化成這樣，然後我們再對一個個選項進行逐一理解。
mtr [OPTIONS] HOSTNAME
-h, --help：顯示命令語法的簡要情況。
-v, --version：顯示版本。這個還是有點重要的，不同版本的mtr輸出的結果可能不同。
-r, --report：使用報告模式（report mode）。上面我們演示過了，默認情況下運行mtr會進入TUI界面，如果我們不希望mtr進入TUI而只是希望其像其他命令一樣直接輸出結果的話，我們可以使用報告模式。
# mtr -r 8.8.8.8 Start: Fri Mar 5 10:56:20 2021 HOST: c7-server Loss% Snt Last Avg Best Wrst StDev 1.|-- gateway 0.0% 10 1.4 1.8 1.1 3.4 0.7 2.|-- 1.114.30.117.broad.xm.fj. 0.0% 10 65.1 24.2 1.6 115.9 38.4 3.|-- 218.85.117.189 0.0% 10 2.5 2.9 2.1 5.1 0.7 4.|-- 61.154.238.65 0.0% 10 3.7 5.1 3.5 7.0 1.2 5.|-- 202.97.82.221 0.0% 10 25.5 22.0 18.7 26.1 2.9 6.|-- 202.97.94.237 20.0% 10 33.6 33.9 32.1 36.2 1.1 7.|-- 202.97.12.186 70.0% 10 19.3 19.6 19.3 20.1 0.0 8.|-- 202.97.50.38 0.0% 10 211.0 218.8 209.9 233.7 8.6 9.|-- 118.85.205.234 0.0% 10 217.1 213.9 205.1 222.2 6.2 10.|-- 72.14.217.174 0.0% 10 243.0 245.9 234.9 262.2 7.1 11.|-- 108.170.241.193 20.0% 10 255.2 256.3 255.2 259.4 1.3 12.|-- 142.250.224.131 0.0% 10 256.4 255.8 254.3 256.5 0.5 13.|-- dns.google 10.0% 10 244.6 244.7 243.8 245.5 0.4
這裏我們對這個報告的每個字段進行一個淺析：
- 從1~13，是一個遞增的序號，表示數據包經過的第幾跳，通過最後一跳的序號我們也可以知道數據包一共經過了幾跳。
- 所經過的路由節點的IP地址，如果支持反向解析的則反解爲主機名。
- Loss%：丟包率。
- Snt：已發送的數據包。
- Last：最近一次數據包的延時，mtr所顯示的延時相關的時間單位均是毫秒。
- Avg：平均延時。
- Best：最小延時。
- Wrst：最大延時。
- Stdev：標準差（Standard Deviation），延時的標準差，這個值越小則延時越穩定。
-c, --report-cycles COUNT：報告模式的默認情況下只會發送10個數據包，我們可以使用-c來指定需要發送的數據包的數量。字段Snt顯示的是發送的數據包。
# mtr -c 5 -r 8.8.8.8
-w, --report-wide：寬（wide）報告模式，默認的報告模式，如果遇到主機名比較長的情況的話，會將其截斷。
1.114.30.117.broad.xm.fj. # 未使用寬報告模式 mtr -w 8.8.8.8 1.114.30.117.broad.xm.fj.dynamic.163data.com.cn # 使用寬報告模式
-s, --psize BYTES：指定數據包的大小，單位是字節。也可以在命令行的尾部指定PACKETSIZE。
mtr -s 100 8.8.8.8 mtr 8.8.8.8 100 # 這種指定方式無結果，不知爲何。
-t, --curses：強制mtr使用curses庫的TUI界面，默認就是該選項。
-e, --mpls：應該是使mtr顯示ICMP擴展中的MPLS信息。MPLS應該是一種多協議的封裝技術，通過避免查詢路由表來加速路由，這應該是一種高級的用法，我也不太瞭解。
-n, --no-dns：不進行主機名的解析。這樣子IP地址就不會反解成主機名了，加快mtr的返回結果的速度。
mtr -n -r 8.8.8.8 gateway <==> 192.168.1.1 1.114.30.117.broad.xm.fj. <==> 117.30.114.1 dns.google <==> 8.8.8.8
-b, --show-ips：同時顯示主機名和IP地址。在分隔（split）模式和報告模式中都可以使用。報告模式中如果被截斷的話就使用寬報告模式。
-g, --gtk：使用基於GTK的GUI，一般用不到。
-p, --split：分隔模式，這種模式適用於split-user interface。我也沒看懂什麼意思。輸出的結果類似於以空格爲分隔符分隔每個字段。
# mtr -p -c 1 8.8.8.8
-l, --raw：將結果輸出成原生（raw）模式，這種模式可以被其他程序所表達。一般用不到。
-x, --xml：輸出成XML格式。
-a, --address IP.ADD.RE.SS：指定mtr探測時數據包從哪個IP地址出去。不過該選項不可用於DNS請求，否則結果可能會出乎意料。
-i, --interval SECONDS：指定每次發送ICMP ECHO請求數據包的間隔時間，單位是秒，默認1秒。這個數只要是正數就行，不一定非得是正整數。
mtr -i 1 8.8.8.8 mtr -i 0.5 8.8.8.8
-m, --max-ttl NUM：指定我們發送的數據包的TTL值。mtr就是通過這個值，來向路由路徑中的每個節點發送數據包。例如在我們的示例中，總共有13個節點，因此如果要設置TTL的話，最小必須設定爲13，否則數據包到不了8.8.8.8。
mtr -m 1 -r -c 1 8.8.8.8 # 1的結果會比較奇怪 mtr -m 2 -r -c 1 8.8.8.8 mtr -m 5 -r -c 1 8.8.8.8 mtr -m 12 -r -c 1 8.8.8.8
-f, --first-ttl NUM：指定我們從第幾個節點開始進行探測，默認是從第一個節點（網關）開始。
mtr -f 5 -r -c 1 8.8.8.8
-B, --bitpattern NUM：指定有效負載中的位模式（bit pattern），值介於0~255。這裏的bit pattern，我的理解是多位的二進制數據，可能是4位、8位、16位等，他們一同來表示某個東西，例如4個字節表示整型int。那麼位模式就是4*8=32。
-Q, --tos NUM：指定IP頭部中的服務類型的值，介於0~255。這裏的服務類型指的是type of service，現在叫做DSCP，是IP頭部的其中一個字段。DSCP一般用於一些實時的數據流，例如IP電話。
-u, --udp：使用UDP數據報文而不是ICMP ECHO。
-T, --tcp：使用TCP SYN數據包而不是ICMP ECHO。使用該選項的話會忽略修改數據包大小的-s、--psize或者PACKETSIZE，因爲SYN數據包不包含數據。
-P, --port PORT：使用TCP追蹤的時候指定目標端口。
--timeout SECONDS：TCP socket保持打開的超時時間（超時則斷開連接）。這個只會影響最後1跳。如果這個值較大並且間隔時間（-i）較短的話，那麼將會使用掉大量的文件描述符。
-4和-6：僅顯示ipv4或者ipv6，一般用不到的選項，因爲現在基本上都還是使用ipv4。
-o, --order fields order：指定要輸出的字段信息。這個選項是一個比較重要的選項。
- L：lose ratio，丟包率。
- D：dropped packets，已丟棄的數據包。
- R：received packets，已接收的數據包。
- S：sent packets，已發送的數據包。
- N：newest RTT，最近的延遲，單位是毫秒。RTT指的是Round-Trip Time，表示數據包一去一回的時間。
- B：best/min RTT，最優的/最小的延遲。
- A：average RTT，平均延遲。
- W：worst/max RTT，最差的/最大的延遲。
- V：standard deviation，延時的標準差。表示每一次的延時和平均延時的差距。數值越小網絡越穩定。
- G：getmetric mean，幾何平均數。與算術平均數不同，理解它是個難點。
- J：current jitter，當前抖動。
- M：mean/average jitter，平均抖動。
- X：worst jitter，最大抖動。
- I：interarrival jitter。
報告解析
參考資料：
如果沒有明確說明，那麼【結果解析】中的mtr輸出來自Linode。
% 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
以數字開頭的每一行數據表示數據包所經過的每個路由節點，也稱之爲跳（hop）。我們主要關心的數據是延遲和丟包。延遲主要通過平均延遲Avg來判斷。標準差用來表示平均延遲的信息是否更接近真實情況，標準差的值越大，那麼平均延遲的可信度越低。
大體上我們可以把所有的路由節點劃分爲三段：
- 前2~3個節點一般是本地ISP段，假設我們是在用戶的PC上鍵入mtr進行測試的話，那麼就是客戶本地的ISP段，例如家庭/小區的寬帶/光纖。如果是這段節點異常，我們應該聯繫本地的電信/移動等ISP。
- 後2~3個節點一般是目標ISP段，目標一般是一些服務的提供商。比如我們購物的淘寶網，或者玩遊戲時遊戲運營商的遊戲服務器所處的網絡。如果是這段節點異常，我們應該聯繫淘寶網/遊戲的客服聯繫技術人員處理。
- 中間節點。中間節點可能很多，一般會經過一些骨幹網，跨越城市、省份、國家或者大洲的廣域網絡。如果是中間節點有問題的話，一般我們本地ISP和目標ISP都沒什麼辦法。
丟包
一般來說，一旦我們看mtr輸出中的某個節點的丟包突然很高，那麼我們可能會認爲那個節點出問題了。不過，對於大多數路由節點，它們會降低響應ICMP echo request數據包，甚至不相應。因爲此類數據包一般用於網絡探測，而不作爲真實的網絡流量數據存在。因此單純的丟包不能代表真實的丟包情況，可能mtr命令發送的ICMP數據包被100%丟棄，但是真實流量的數據包就不丟棄了。如果我們想判斷到底是ICMP流量限制還是真實丟包情況的話，可以看丟包節點的後續節點是否出現丟包。如果像下面這樣後續節點都不丟包的話，那麼可以理解爲該丟包應該是由於ICMP流量限制。
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流量限制和丟包可能同時發生！
像這個示例中，我們認爲丟包節點的後續節點中的最低丟包率爲真實的丟包率，即40%。
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節點產生丟包，由0%升至60%，並且後續的節點均沒有出現無丟包情況，因此可以判斷從該節點開始應該是真的丟包了。第3第4節點丟包60%，後續節點逐漸下降至40%直至末節點，此類情況我們一般選擇靠後的最低的丟包率作爲真實丟包率。因此從結果來看真實丟包率應該在40%左右，其中中間節點可能有10%~20%左右的由於ICMP流量限制出現丟包。這個10%和20%是取節點丟包率與真實丟包率的差。
有的時候，數據包發送過去沒問題，但是在回來的途中可能有問題。這個時候一般是建議進行雙向mtr來結合判斷網絡情況。
由於網絡協議在設計之初對於一些網絡降級（degrade）的情況具備一些彈性，並且路由可能因爲各種各樣的問題多多少少會有一些波動的情況。因此不用強迫自己去深究每一處丟包，10%左右的丟包並不是我們主要關心的問題，可能應用層就可以補償掉這些丟包帶來的損失了。
延遲
一般來說，隨着距離的增長和節點的增加，延遲都是越來越高的。不過在同一個網絡/地區下，一般是穩步地線性地增加。延遲非常依賴於測試時的線路質量，因此在查看延遲數據的時候，最好是有一個正常情況下的延遲數據記錄來做對比會比較好。這裏的正常情況下應該指的是軟件/應用可以在當下的延遲下提供完整的功能等。
線路質量也會受到物理層的影響，例如撥號上網（dial-up）的線路的延遲一定是大於我們現在所廣泛使用的雙絞線、光纖的。
root@localhost:~# 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
像該示例中從第4節點開始，延遲暴增並且維持到了末節點。那麼我們就可以判斷真的是有延遲問題發生了。即便常見的原因可能是飽和的對等會話（saturated peering session）、路由器配置不良或者堵塞的鏈路，但是我們基本不可能找出真實的原因。
不過有時候延遲可能也不是個問題，比如上面示例中即便出現了高延遲，但是數據包依然抵達了目標節點。延遲也可能受到返回路由的影響。但是數據包返回的路線可能與當時去的路線完全不同。
譯者注：到這裏有一個疑問點，如果雙向mtr測試的路徑不同的話，那麼其參考價值會有多大？
從上面的示例來看，從第4節點開始延時暴增並且後續節點的延遲沒有出現較大程度的上下波動，因此我們可以認爲導致該延遲的原因出在第4節點。
ICMP流量限制除了會造成丟包的表象之外，也會造成延遲的表象。
root@localhost:~# 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
第一眼我們會認爲第5節點出問題了，因此延遲從10ms以內瞬間激增至250ms左右。此時應該和判斷丟包類似，我們要看後面的延遲情況。隨後節點的延遲一直保持在40ms左右，因此真實的延遲應該就只是在40ms左右。而第5節點的250ms很可能是由於該節點對ICMP數據包有做了流量的限制。如果隨後節點的延遲維持在250ms，那麼可能延遲真的就是250ms；如果隨後節點的延遲降低到了0ms，那麼第5節點的250ms的延遲很可能全部都是由於ICMP流量限制導致的。
常見報告
目標主機網絡配置不當
root@localhost:~# 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
第一眼看這個報告的時候，我們主要會關注到到末節點的數據包100%丟失。末節點的話，就是目標網絡ISP段的數據，且是最後一個節點。由於是最後一個節點，我們就無法判斷後續的節點的丟包情況了。ICMP的流量限制一般是發生在中間的節點，而且一般要結合後續節點來判斷是否是流量的限制。
因此像這種情況就一般不會是中間路由節點的ICMP流量限制了。比較可能的情況是末節點的服務器（可能）的網絡配置問題。如果真實的數據包也無法抵達的話，那麼可能是防火牆配置錯誤了。當然也可能是服務器直接配置了拒絕響應ICMP數據包。
住宅（residential）或者商業（business）路由器
% 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
現象：第2節點（前幾個）全丟包且沒有IP地址。這種可能是本地ISP的配置的問題，問號的節點可能是本地的住宅網關。從丟包節點後續來看也都沒有丟包。因此這個節點丟包應該只是不響應ICMP數據包而已。並且我認爲之所以沒顯示節點IP可能也是因爲節點拒絕響應ICMP的某些信息。
ISP路由器配置不當
如果目標主機無法正常訪問，並且mtr報告中在某節點後的節點均是???的話，那麼可能是最後一個有效節點或者其之後的某個路由配置有問題導致的。
root@localhost:~# 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
這邊的???我覺得和上個例子的不太一樣。上面住宅網關的???只是某個節點而已，並且存在丟包的情況。而這裏的情況是從某個節點之後連續到末尾的所有節點，並且丟包和延遲的結果都一樣都是0。應該是到第4節點就停止了（mtr都不知道後續節點是什麼），而不是說其之後的節點不響應mtr的數據包。
也有一些比較明顯的可以看出來的，例如路由器配置不當導致的路由死循環。
root@localhost:~# 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或者第5節點，解決的辦法只能嘗試去判斷錯誤節點的歸屬ISP，然後去聯繫處理。
ICMP比例限制
也就是我說的流量限制。
root@localhost:~# 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協議僅僅是一個支撐/協助的協議，用來對網絡進行探測的，而不是真實的數據流量。爲了將有限的帶寬更多地讓給真實有效的數據，因此路由節點（尤其是骨幹網）會針對ICMP做流量限制。
超時
超時的原因可能有很多。比如節點直接丟棄了ICMP數據包或者ICMP響應數據包返回失敗了，那麼在報告中就會呈現出“???”。
root@localhost:~# 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
超時不是丟包的必要現象，即出現丟包不一定必須有超時的情況。超時可能是爲了QoS使得路由器丟棄數據包或者ICMP響應數據包返回失敗。
高級
較新版本的mtr工具支持使用TCP數據包來探測，但是大多數情況下都不應該使用這類數據包。因爲基於tcp的mtr使用SYN數據包來探測而大多數路由節點並不會響應這類數據包。
不過在一些特定的場景下，還是可以使用TCP數據包的。當我們需要判斷某些防火牆規則的時候，我們可以使用TCP數據包來針對那些協議或者端口進行判斷，也許可能是端口轉發配置不當。
sudo mtr --tcp --port 80 --report --report-cycles 10 speedtest.dallas.linode.com sudo mtr --tcp --port 22 --report --report-cycles 10 50.116.25.154
小結
這篇文章大概闡述了mtr命令的用法，重點和難點在於對於mtr報告的理解。但是即便正確理解了報告，對於一些網絡問題我們可能也無能爲力。一個數據包從我們源頭抵達目標主機所經過的網絡段會有很多，包含本地ISP、中間ISP和目標ISP。中間ISP更可能涉及到不同的國家，所以一旦是中間ISP出現問題，那麼基本上是隻能聽天由命了。
我們可以做的就是儘可能正確理解mtr的報告，並且做好報告提供給ISP。
高級功能中我們可以使用TCP/UDP協議針對特定的協議和端口進行探測是我們運維人員可能比較需要的功能。
但是所有的這些網絡相關的工具，想要使用好就必須要求我們具備一定的網絡知識基礎，比如TCP/IP協議基礎。