參數(shù)說明
-r or --report
使用 mtr -r qq.com 來打印報告，如果不使用 -r or --report 參數(shù) mtr 會不斷動態(tài)運行氓癌。使用 report 選項， mtr 會向 qq.com 主機發(fā)送 10 個 ICMP 包，然后直接輸出結(jié)果袁勺。通常情況下 mtr 需要幾秒鐘時間來輸出報告柱徙。mtr 報告由一系列跳數(shù)組成缓屠，每一跳意味著數(shù)據(jù)包通過節(jié)點或者路由器來達到目的主機。
一般情況下 mtr 前幾跳都是本地 ISP护侮，后幾跳屬于服務(wù)商比如 騰訊數(shù)據(jù)中心敌完，中間跳數(shù)則是中間節(jié)點，如果發(fā)現(xiàn)前幾跳異常羊初，需要聯(lián)系本地 ISP 服務(wù)提供上滨溉，相反如果后幾跳出現(xiàn)問題，則需要聯(lián)系服務(wù)提供商长赞，中間幾跳出現(xiàn)問題晦攒，則需要聯(lián)系運營商進行處理
默認使用 -r 參數(shù)來生成報告，只會發(fā)送10個數(shù)據(jù)包得哆，如果想要自定義數(shù)據(jù)包數(shù)量脯颜，可以使用 -c 參數(shù)
-s or --packetsize
使用 -s 來指定ping數(shù)據(jù)包的大小
mtr -s 100 qq.com
100 bytes 數(shù)據(jù)包會用來發(fā)送，測試贩据，如果設(shè)置為負數(shù)栋操，則每一次發(fā)送的數(shù)據(jù)包的大小都會是一個隨機數(shù)。
-c
指定發(fā)送數(shù)量
mtr -c 100 qq.com
-n
不進行主機解釋
使用 -n 選項來讓 mtr 只輸出 IP饱亮，而不對主機 host name 進行解釋
mtr -n qq.com
MTR結(jié)果分析
當我們分析 MTR 報告時候矾芙，最好找出每一跳的任何問題。除了可以查看兩個服務(wù)器之間的路徑之外近上，MTR 在它的七列數(shù)據(jù)中提供了很多有價值的數(shù)據(jù)統(tǒng)計報告剔宪。Loss% 列展示了數(shù)據(jù)包在每一跳的丟失率。Snt 列記錄的多少個數(shù)據(jù)包被送出。使用 –report 參數(shù)默認會送出10個數(shù)據(jù)包葱绒。如果使用 –report-cycles=[number-of-packets] 選項感帅，MTR 就會按照 [number-of-packets] 指定的數(shù)量發(fā)出 ICMP 數(shù)據(jù)包。
Last, Avg, Best 和 Wrst 列都標識數(shù)據(jù)包往返的時間哈街，使用的是毫秒（ ms ）單位表示留瞳。Last 表示最后一個數(shù)據(jù)包所用的時間， Avg 表示評價時間骚秦， Best 和 Wrst 表示最小和最大時間她倘。在大多數(shù)情況下，平均時間（ Avg）列需要我們特別注意作箍。
最后一列 StDev 提供了數(shù)據(jù)包在每個主機的標準偏差硬梁。如果標準偏差越高，說明數(shù)據(jù)包在這個節(jié)點的延時越不相同胞得。標準偏差會讓您了解到平均延時是否是真的延時時間的中心點荧止，或者測量數(shù)據(jù)受到某些問題的干擾。
例如阶剑，如果標準偏差很大跃巡，說明數(shù)據(jù)包的延遲是不確定的。一些數(shù)據(jù)包延遲很心脸睢（例如：25ms）素邪，另一些數(shù)據(jù)包延遲很大（例如：350ms）。當10個數(shù)據(jù)包全部發(fā)出后猪半，得到的平均延遲可能是正常的兔朦，但是平均延遲是不能很好的反應(yīng)實際情況的。如果標準偏差很高磨确，使用最好和最壞的延遲來確定平均延遲是一個較好的方案恃泪。
在大多數(shù)情況下窃蹋，您可以把 MTR 的輸出分成三大塊。根據(jù)配置施蜜，第二或第三跳一般都是您的本地 ISP挽拔，倒數(shù)第二或第三跳一般為您目的主機的ISP汇恤。中間的節(jié)點是數(shù)據(jù)包經(jīng)過的路由器癣防。
當分析 MTR 的輸出時绍豁，您需要注意兩點：loss 和 latency。
網(wǎng)絡(luò)丟包
如果在任何一跳上看到 loss 的百分比驶悟，這就說明這一跳上可能有問題了。當然材失，很多服務(wù)提供商人為限制 ICMP 發(fā)送的速率痕鳍，這也會導致此問題。那么如何才能指定是人為的限制 ICMP 傳輸 還是確定有丟包的現(xiàn)象？此時需要查看下一跳笼呆。如果下一跳沒有丟包現(xiàn)象熊响，說明上一條是人為限制的。如下示例：
人為限制MTR丟包
在此例中诗赌，第4跳發(fā)生了丟包現(xiàn)象汗茄，但是接下來幾條都沒任何丟包現(xiàn)象，說明第二跳的丟包是人為限制的铭若。如果在接下來的幾條中都有丟包洪碳，那就可能是第二跳有問題了。請記住叼屠，ICMP 包的速率限制和丟失可能會同時發(fā)生瞳腌。
MTR丟包截圖
從上面的圖中，您可以看從第13跳和第17跳都有 10% 的丟包率镜雨，從接下來的幾跳都有丟包現(xiàn)象嫂侍，但是最后15,16跳都是100%的丟包率，我們可以猜測到100%的丟包率除了網(wǎng)絡(luò)糟糕的原因之前還有人為限制 ICMP荚坞。所以挑宠，當我們看到不同的丟包率時，通常要以最后幾跳為準颓影。
還有很多時候問題是在數(shù)據(jù)包返回途中發(fā)生的各淀。數(shù)據(jù)包可以成功的到達目的主機，但是返回過程中遇到“困難”了瞭空。所以揪阿，當問題發(fā)生后，我們通常需要收集反方向的 MTR 報告咆畏。
此外南捂，互聯(lián)網(wǎng)設(shè)施的維護或短暫的網(wǎng)絡(luò)擁擠可能會帶來短暫的丟包率，當出現(xiàn)短暫的10%丟包率時候旧找，不必擔心溺健，應(yīng)用層的程序會彌補這點損失。
網(wǎng)絡(luò)延遲
除了可以通過MTR報告查看丟包率钮蛛，我們也還可以看到本地到目的之間的時延鞭缭。因為是不通的位置，延遲通常會隨著條數(shù)的增加而增加魏颓。所以岭辣，延遲通常取決于節(jié)點之間的物理距離和線路質(zhì)量。
MTR查看網(wǎng)絡(luò)延遲
從上面的MTR報告截圖中甸饱，我們可以看到從第11跳到12跳的延遲猛增沦童，直接導致了后面的延遲也很大仑濒，一般有可能是11跳到12跳屬于不通地域，物理距離導致時延猛增偷遗，也有可能是第12條的路由器配置不當墩瞳，或者是線路擁塞。需要具體問題進行具體的分析氏豌。
然而喉酌，高延遲并不一定意味著當前路由器有問題。延遲很大的原因也有可能是在返回過程中引發(fā)的泵喘。從這份報告的截圖看不到返回的路徑泪电，返回的路徑可能是完全不同的線路，所以一般需要進行雙向MTR測試涣旨。
注：ICMP 速率限制也可能會增加延遲歪架，但是一般可以查看最后一條的時間延遲來判斷是否是上述情況。
根據(jù)MTR結(jié)果解決網(wǎng)絡(luò)問題
MTR 報告顯示的路由問題大都是暫時性的霹陡。很多問題在24小時內(nèi)都被解決了和蚪。大多數(shù)情況下，如果您發(fā)現(xiàn)了路由問題烹棉，ISP 提供商已經(jīng)監(jiān)視到并且正在解決中了攒霹。當您經(jīng)歷網(wǎng)絡(luò)問題后，可以選擇提醒您的 ISP 提供商浆洗。當聯(lián)系您的提供商時催束，需要發(fā)送一下 MTR 報告和相關(guān)的數(shù)據(jù)。沒有有用的數(shù)據(jù)伏社，提供商是沒有辦法去解決問題的抠刺。
然而大多數(shù)情況下，路由問題是比較少見的摘昌。比較常見的是因為物理距離太長速妖，或者上網(wǎng)高峰，導致網(wǎng)絡(luò)變的很慢聪黎。尤其是跨越大西洋和太平洋的時候罕容，網(wǎng)絡(luò)有時候會變的很慢。這種情況下稿饰，建議就近接入客戶的節(jié)點锦秒。
來源：
