概述
當客戶端訪問目標服務器或負載均衡，使用ping命令測試出現丟包或不通時，可以通過MTR等工具進行鏈路測試來判斷問題來源。本文先介紹了MTR工具的基本原理，然后對測試結果進行分析，以及對測試步驟進行了說明。
詳細信息
MTR基本信息
- MTR（My traceroute）是幾乎所有Linux發行版本預裝的網絡測試工具，此工具也有對應的Windows版本，名稱為WinMTR。
-
MTR工具將ping和traceroute命令的功能並入了同一個工具中，實現更強大的功能。
-
Linux版本的mtr命令默認發送ICMP數據包進行鏈路探測。可以通過“-u”參數來指定使用UDP數據包用於探測。
-
相對於traceroute命令只會做一次鏈路跟蹤測試，mtr命令會對鏈路上的相關節點做持續探測並給出相應的統計信息。所以，mtr命令能避免節點波動對測試結果的影響，所以其測試結果更正確，建議優先使用。
在Windows系統上使用
WinMTR是MTR工具在Windows環境下的圖形化實現，但進行了功能簡化，只支持MTR部分參數的調整設置。WinMTR默認發送ICMP數據包進行探測，無法切換。
WinMTR可以從其官方網站下載獲取。和mtr命令一樣，相比tracert，WinMTR能避免節點波動對測試結果的影響，所以測試結果更正確。
所以，在WinMTR可用的情況下，建議優先使用 WinMTR 進行鏈路測試。
用法說明
WinMTR無需安裝，直接解壓運行即可，操作方法非常簡單。運行程序后，在Host字段輸入目標服務器域名或 IP，注意前面不要包含空格。如下圖所示
單擊Start開始測試，開始測試后，相應按鈕變成了Stop。運行一段時間后，單擊Stop停止測試。其它選項說明：
-
Copy Text to clipboard：將測試結果以文本格式復制到粘貼板。
-
Copy HTML to clipboard：將測試結果以HTML格式復制到粘貼板。
-
Export TEXT：將測試結果以文本格式導出到指定文件。
-
Export HTML：將測試結果以HTML格式導出到指定文件。
-
Options：可選參數，包括：
-
Interval（sec）：每次探測的間隔（過期）時間。默認為1秒。
-
Ping size(bytes)： PING探測所使用的數據包大小，默認為64字節。
-
Max hosts in LRU list： LRU列表支持的最大主機數，默認值為128。
-
Resolve names：通過反查IP以域名顯示相關節點。
返回結果
默認配置下，返回結果中各數據列的說明：
-
第一列（Hostname）：節點IP或域名。
-
第二列（Nr）：節點編號。
-
第三列（Loss%）：節點丟包率。
-
第四列（Sent）：已發送的數據包數量。
-
第五列（Recv）：已成功接收的數據包數量。
-
第六、七、八、九列（Best 、Avg、Worst、Last）：分別是到相應節點延遲的最小值、平均值、最大值和最后一次值。
-
第八列（StDev）：標准偏差，越大說明相應節點越不穩定。
通常情況下，鏈路測試流程如下圖所示。
獲取本地網絡對應公網IP
在客戶端本地網絡訪問淘寶IP地址庫等網站，獲取本地網絡對應的公網IP。
正向鏈路測試（PING和MTR）
從客戶端向目標服務器做PING和MTR鏈路測試。從客戶端向目標服務器域名或IP做持續的PING測試，建議至少測試100個數據包，記錄測試結果。根據客戶端操作系統環境的不同，使用WinMTR或mtr命令，設置測試目的地址為目標服務器域名或IP，然后進行鏈路測試，記錄測試結果。
反向鏈路測試（PING和MTR）
進入目標服務器系統內部，做反向PING和MTR鏈路測試。從目標服務器向客戶端IP做持續的PING測試，建議至少測試100個數據包，記錄測試結果。根據目標服務器操作系統環境的不同，使用WinMTR或mtr命令，設置測試目的地址為客戶端IP，然后進行鏈路測試，記錄測試結果。
測試結果分析
參閱前述說明，對測試結果進行分析。確認異常節點后，訪問淘寶IP地址庫等網站查詢、獲取相應節點歸屬運營商及網絡。如果是客戶端本地網絡相關節點出現異常，則需要對本地網絡進行相應排查分析。如果是運營商相關節點出現異常，則需要直接聯系運營商，或聯系阿里雲售后技術支持向相應運營商反饋問題。
鏈路測試結果分析簡要說明
由於mtr（WinMTR）命令有更高的准確性，本文以其測試結果為例，對鏈路測試結果的分析進行簡要說明。后續的說明，以如下鏈路測試結果示例圖為基礎進行闡述。
對鏈路測試結果進行分析時，需要關注如下幾點：
-
網絡區域
-
鏈路負載均衡
-
結合Avg（平均值）和 StDev（標准偏差）綜合判斷
-
Loss%（丟包率）的判斷
-
延遲
網絡區域
正常情況下，從客戶端到目標服務器的整個鏈路，會顯著的包含如下區域。
客戶端本地網絡：本地局域網和本地網絡提供商網絡。如前文鏈路測試結果示例圖中的區域A。如果該區域出現異常，如果是客戶端本地網絡相關節點出現異常，則需要對本地網絡進行相應排查分析。否則，如果是本地網絡提供商網絡相關節點出現異常，則需要向當地運營商反饋問題。
運營商骨干網絡：如前文鏈路測試結果示例圖中的區域B。如果該區域出現異常，可以根據異常節點IP查詢歸屬運營商，然后直接或通過阿里雲售后技術支持，向相應運營商反饋問題。
目標服務器本地網絡：目標主機歸屬網絡提供商網絡。如前文鏈路測試結果示例圖中的區域C。如果該區域出現異常，則需要向目標主機歸屬網絡提供商反饋問題。
鏈路負載均衡：如前文鏈路測試結果示例圖中的區域D。如果中間鏈路某些部分啟用了鏈路負載均衡，則mtr命令只會對首尾節點進行編號和探測統計。中間節點只會顯示相應的IP或域名信息。
結合Avg（平均值）和StDev（標准偏差）綜合判斷
由於鏈路抖動或其它因素的影響，節點的Best和Worst值可能相差很大。而Avg（平均值）統計了自鏈路測試以來所有探測的平均值，所以能更好的反應出相應節點的網絡質量。而StDev（標准偏差值）越高，則說明數據包在相應節點的延時值越不相同（越離散）。所以標准偏差值可用於協助判斷Avg是否真實反應了相應節點的網絡質量。例如，如果標准偏差很大，說明數據包的延遲是不確定的。可能某些數據包延遲很小（例如：25ms），而另一些延遲卻很大（例如：350ms），但最終得到的平均延遲反而可能是正常的。所以此時Avg並不能很好的反應出實際的網絡質量情況。
綜上，建議的分析標准如下：
-
如果StDev很高，則同步觀察相應節點的Best和Wrst，來判斷相應節點是否存在異常。
-
如果StDev不高，則通過Avg來判斷相應節點是否存在異常。
說明：上述StDev“高”或者“不高”，並沒有具體的時間范圍標准。而需要根據同一節點其它列的延遲值大小來進行相對評估。例如，如果Avg為30ms，那么，當StDev為25ms，則認為是很高的偏差。而如果Avg為325ms，則同樣的StDev（25ms），反而認為是不高的偏差。
Loss%（丟包率）的判斷
任一節點的Loss%（丟包率）如果不為零，則說明這一跳網絡可能存在問題。導致相應節點丟包的原因通常有兩種。
-
運營商基於安全或性能需求，人為限制了節點的ICMP發送速率，導致丟包。
-
節點確實存在異常，導致丟包。
可以結合異常節點及其后續節點的丟包情況，來判定丟包原因。
-
如果隨后節點均沒有丟包，則通常說明異常節點丟包是由於運營商策略限制所致。可以忽略相關丟包。如前文鏈路測試結果示例圖中的第2跳所示。
-
如果隨后節點也出現丟包，則通常說明異常節點確實存在網絡異常，導致丟包。如前文鏈路測試結果示例圖中的第5跳所示。
-
另外，需要說明的是，前述兩種情況可能同時發生。即相應節點既存在策略限速，又存在網絡異常。對於這種情況，如果異常節點及其后續節點連續出現丟包，而且各節點的丟包率不同，則通常以最后幾跳的丟包率為准。如前文鏈路測試結果示例圖所示，在第 5、6、7跳均出現了丟包。所以，最終丟包情況，以第7跳的40%作為參考。
關於延遲
延遲跳變
如果在某一跳之后延遲明顯陡增，則通常判斷該節點存在網絡異常。如前文鏈路測試結果示例圖所示，從第5跳之后的后續節點延遲明顯陡增，則推斷是第5跳節點出現了網絡異常。不過，高延遲並不一定完全意味着相應節點存在異常。如前文鏈路測試結果示例圖所示，第5跳之后，雖然后續節點延遲明顯陡增，但測試數據最終仍然正常到達了目的主機。所以，延遲大也有可能是在數據回包鏈路中引發的。所以，最好結合反向鏈路測試一並分析。
ICMP限速導致延遲增加
ICMP策略限速也可能會導致相應節點的延遲陡增，但后續節點通常會恢復正常。如前文鏈路測試結果示例圖所示，第3跳有 100%的丟包率，同時延遲也明顯陡增。但隨后節點的延遲馬上恢復了正常。所以判斷該節點的延遲陡增及丟包是由於策略限速所致。
常見鏈路異常場景和測試報告分析
目標主機網絡配置不當
如上圖所示，在該示例中，數據包在目標地址出現了100%的丟包。乍一看是數據包沒有到達，其實很有可能是目標服務器相關安全策略，例如防火牆、iptables等禁用了ICMP所致，導致目的主機無法發送任何應答。所以，該場景需要排查目標服務器的安全策略配置。
ICMP限速
如上圖所示，在該示例中，數據包在目標地址出現了100%的丟包。初步看是數據包沒有到達，其實很有可能是目標服務器相關安全策略，例如防火牆、iptables 、運營商策略等禁用了ICMP所致，導致目的主機無法發送任何應答。所以，該場景需要排查目標服務器的安全策略配置，或結合反向MTR綜合分析。
環路
如上圖所示，在該示例中數據包在第5跳之后出現了循環跳轉，導致最終無法到達目標服務器。這通常是由於運營商相關節點路由配置異常所致。所以，該場景需要聯系相應節點歸屬運營商處理。
鏈路中斷
如上圖所示，在該示例中，數據包在第4跳之后就無法收到任何反饋。這通常是由於相應節點中斷所致。建議結合反向鏈路測試做進一步確認。該場景需要聯系相應節點歸屬運營商處理。