原文發(fā)表于：如何用 MTR 診斷網(wǎng)絡(luò)問題？---下篇
從如何用 MTR 診斷網(wǎng)絡(luò)問題站辉？（上）我們了解了什么是 MTR呢撞，以及如何生成一份報(bào)告等知識(shí)。這里饰剥，我們深入分析一下 MTR 報(bào)告的含義殊霞，以及常見的 MTR 結(jié)果分析。
分析 MTR 報(bào)告
驗(yàn)證數(shù)據(jù)包丟失
在分析 MTR 輸出時(shí)汰蓉，您正在尋找兩件事情：丟包和延遲绷蹲。首先讓我們來談?wù)剚G包。如果您在任何特定跳點(diǎn)看到一定百分比的丟失古沥，這可能表明該特定路由器存在問題瘸右。然而，一些服務(wù)提供商通常的做法是限制 MTR 使用的ICMP流量岩齿。這實(shí)際上沒有損失可以給出丟包的錯(cuò)覺太颤。要確定您看到的損失是真實(shí)的還是由于速率限制，請(qǐng)查看隨后的一跳盹沈，如果該跳丟包率是0.0％龄章，那么您可以確定您看到 ICMP 速率限制吃谣，而不是實(shí)際丟包。參見下面的例子：
root@localhost:~# 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
在這種情況下做裙，第一跳和第二跳之間報(bào)告的丟包可能是由于第二跳速率限制岗憋。雖然剩下的八跳的流量都觸及第二跳，但是沒有丟包锚贱。如果丟失持續(xù)多于一個(gè)跳仔戈，則可能存在一些丟包或路由問題。請(qǐng)記住拧廊，速率限制和丟失可能同時(shí)發(fā)生监徘。在這種情況下，將序列中的最低損失百分比作為實(shí)際損失吧碾。例如凰盔，考慮以下輸出：
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? ? ? ? ? ? ? ? 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
在這種情況下，您會(huì)看到跳數(shù)2和3之間以及跳數(shù)3和4之間的損失為60％倦春。您可以假設(shè)第三跳和第四跳可能會(huì)丟失一定數(shù)量的流量户敬，因?yàn)楹罄m(xù)的主機(jī)報(bào)告零損失。然而睁本，一些損失是由于速率限制尿庐，因?yàn)閹讉€(gè)最終的跳數(shù)只有40％的損失。報(bào)告不同數(shù)量的損失時(shí)添履，請(qǐng)始終信任來自后期的報(bào)告屁倔。
一些損失也可以通過返回路線中的問題來解釋。數(shù)據(jù)包將無錯(cuò)誤地到達(dá)目的地暮胧，但很難做出回程。這在報(bào)告中很明顯问麸，但可能難以從 MTR 的輸出中推斷出來往衷。因此，當(dāng)您遇到問題時(shí)严卖，通常最好雙向收集 MTR 報(bào)告席舍。
另外，抵制調(diào)查或報(bào)告您的連接中所有丟包發(fā)生的誘惑哮笆±床互聯(lián)網(wǎng)協(xié)議被設(shè)計(jì)為對(duì)一些網(wǎng)絡(luò)退化具有彈性，并且數(shù)據(jù)跨 Internet 的路由可以響應(yīng)于負(fù)載稠肘，簡(jiǎn)短的維護(hù)事件和其他路由問題而波動(dòng)福铅。如果您的 MTR 報(bào)告顯示10％附近的少量損失，則沒有任何理由引起真正的關(guān)注项阴，因?yàn)閼?yīng)用層將補(bǔ)償可能短暫的丟包滑黔。
了解網(wǎng)絡(luò)延遲
除了幫助您評(píng)估數(shù)據(jù)包丟失之外，MTR 還將幫助您評(píng)估主機(jī)與目標(biāo)主機(jī)之間的連接延遲。由于物理限制略荡，延遲總是隨著路由中的跳數(shù)而增加庵佣。但是，增幅應(yīng)該是一致和線性的汛兜。不幸的是巴粪，延遲通常是相對(duì)的，并且非常依賴于主機(jī)連接的質(zhì)量和它們的物理距離粥谬。在評(píng)估可能存在問題的連接的地鐵報(bào)告時(shí)验毡，除了在給定區(qū)域內(nèi)的其他主機(jī)之間的已知連接速度之外，還可以將早期的全功能報(bào)告視為上下文帝嗡。
連接質(zhì)量也可能會(huì)影響特定路由的延遲時(shí)間晶通。可以預(yù)見的是哟玷，撥號(hào)連接將比同一目的地的電纜調(diào)制解調(diào)器連接具有更高的延遲狮辽。考慮以下地鐵報(bào)告顯示高延遲：
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
跳數(shù)在跳數(shù)3和4之間顯著跳躍巢寡，并保持高電平喉脖。這可能指向網(wǎng)絡(luò)延遲問題，因?yàn)樵诘谒奶蟮耐禃r(shí)間保持較高抑月。從這個(gè)報(bào)告來看树叽，不可能確定原因，盡管飽和的對(duì)等會(huì)話谦絮，配置不良的路由器或擁塞的鏈路是比較頻繁的原因题诵。
不幸的是，高延遲并不總是意味著當(dāng)前路由的問題层皱。像上面這樣的報(bào)告意味著性锭，盡管第四跳有某種問題，但流量仍然到達(dá)目的地主機(jī)并返回到源主機(jī)叫胖。延遲可能是由于返回路線的問題引起的草冈。您的 MTR 報(bào)告中不會(huì)顯示返回路由，并且數(shù)據(jù)包可以采取與特定目的地完全不同的路由瓮增。
在上面的例子中怎棱，雖然主機(jī)3和4之間的延遲有很大的跳躍，但延遲在任何后續(xù)跳都不會(huì)異常增加绷跑。從這一點(diǎn)來說拳恋，假設(shè)第四個(gè)路由器有一些問題是合乎邏輯的。
ICMP 速率限制還可以產(chǎn)生類似延遲的現(xiàn)象你踩，類似于它可以產(chǎn)生類似丟包的現(xiàn)象诅岩。請(qǐng)考慮以下示例：
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
乍看之下讳苦，跳數(shù)4和5之間的延遲引起了關(guān)注。然而吩谦，在第五跳之后鸳谜，潛伏期急劇下降。這里測(cè)量的實(shí)際延遲約為40ms式廷。在這種情況下咐扭，中期審查提請(qǐng)注意不影響服務(wù)的問題。在評(píng)估 MTR 報(bào)告時(shí)滑废，考慮到最后一跳的延遲蝗肪。
解決您的 MTR 報(bào)告中確定的路由和網(wǎng)絡(luò)問題
審查報(bào)告顯示的大部分路由問題是暫時(shí)的。大多數(shù)問題將在24小時(shí)內(nèi)自行清理蠕趁。在大多數(shù)情況下薛闪，當(dāng)您能夠注意到路由問題時(shí)，Internet服務(wù)提供商的監(jiān)控已經(jīng)報(bào)告了問題俺陋，管理員正在努力解決問題豁延。如果您在長(zhǎng)時(shí)間內(nèi)遇到劣化服務(wù)的情況，您可以選擇向提供商提醒您遇到的問題腊状。聯(lián)系服務(wù)提供商時(shí)诱咏，可以發(fā)送MTR 報(bào)告和您可能擁有的任何其他相關(guān)數(shù)據(jù)。
