當用戶端訪問目標伺服器或負載平衡器時，如果在使用ping命令進行測試時出現丟包或網路不通的情況，可以通過鏈路測試載入器進行鏈路測試，以判斷問題的原因。本文將介紹如何使用鏈路測試載入器進行鏈路測試，並提供分析鏈路測試結果的一些思路。
測試流程
通常情況下，鏈路測試流程如下圖所示。
您可以訪問IP地址查詢等網站，擷取本網對應的公網IP地址。
工具介紹
MTR是一款網路診斷工具，其將ping和traceroute的功能合并，相對於traceroute只會做一次鏈路跟蹤測試，mtr會對鏈路上的相關節點做持續探測並給出相應的統計資訊。因此，mtr能避免節點波動對測試結果的影響，所以其測試結果更正確。
如果您使用Linux系統，您可以通過安裝mtr軟體包來使用mtr。對於Windows系統，您可以選擇使用WinMTR。有關以上兩種工具的安裝及使用說明，請參考如下介紹。
mtr（Linux）
安裝說明
CentOS 6/7/8
Ubuntu/Debian
使用介紹
命令格式
mtr [-hvrctglspni46] [-help] [-version] [-report] [-report-cycles=COUNT] [-curses] [-gtk] [-raw] [-split] [-no-dns] [-address interface] [-psize=bytes/-s bytes] [-interval=SECONDS] HOSTNAME [PACKETSIZE]參數說明
常見的選擇性參數說明如下表所示，您也可以通過man mtr命令查看更多參數說明。
選擇性參數 | 參數說明 |
| 以報告模式顯示輸出。 |
| 將每次鏈路跟蹤的結果分別列出來。 |
| 指定ping資料包的大小。 |
| 不對IP地址做網域名稱反解析。 |
| 設定發送資料包的IP地址。 說明 該參數用於主機存在多個IP地址的情境。 |
-4 | 只使用IPv4協議。 |
-6 | 只使用IPv6協議。 |
運行mtr命令後，系統預設進入互動模式。在此模式下，您可以輸入以下參數，以快速控制mtr工具的行為或切換顯示視圖。
參數 | 參數說明 |
| 顯示協助菜單。 |
| 切換顯示模式。 |
| 啟用或禁用DNS網域名稱解析。 |
| 使用ICMP或UDP資料包進行探測。 |
回顯結果樣本說明
以執行mtr 目標IP地址命令為例，返回結果如下：
預設配置下，返回結果清單中各資料項目的說明如下。
參數 | 參數說明 |
Host | 節點IP地址和網域名稱。您可以按 |
Loss% | 節點丟包率。 |
Snt | 已發送資料包數。預設值是10，可以通過參數 |
Last | 最近一次的探測延遲值。 |
Avg | 探測延遲的平均值。 |
Best | 探測延遲的最小值。 |
Wrst | 探測延遲的最大值。 |
StDev | 標準差。該值越大說明相應節點越不穩定。 |
WinMTR（Windows）
安裝說明
下載WinMTR後無需安裝，直接解壓運行即可，操作方法非常簡單，操作步驟如下。
前往WinMTR官網下載WinMTR。
解壓WinMTR壓縮包，並雙擊運行WinMTR。
使用介紹
在Host中，輸入目標伺服器網域名稱或IP地址。
重要輸入的目標伺服器網域名稱或IP地址不能包含空格。
您還可以使用其他功能或設定其他參數，功能及參數說明如下：
功能或參數
參數說明
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地址以網域名稱顯示相關節點。
單擊Start，開始測試。
開始測試後，Start會自動變成Stop，WinMTR自動顯示測試結果。
運行一段時間後，單擊Stop停止測試。
回顯結果樣本說明
以測試目標伺服器網域名稱為例，返回樣本如下：
預設配置下，返回結果中各資料項目的說明如下：
參數 | 參數說明 |
Hostname | 節點IP地址和網域名稱。 |
Nr | 節點編號。 |
Loss% | 節點丟包率。 |
Sent | 已發送的資料包數量。 |
Recv | 已成功接收的資料包數量。 |
Best | 節點延遲的最小值。 |
Avg | 節點延遲的平均值。 |
Worst | 節點延遲的最大值。 |
Last | 節點延遲的最後一次值。 |
StDev | 標準差。該值越大說明相應節點越不穩定。 |
結果分析指南
由於mtr命令有更高的準確性，本文以mtr命令測試結果為例，對鏈路測試結果的分析進行簡要說明。後續的說明，均以如下鏈路測試結果樣本圖為基礎進行闡述。
網路地區說明
通常情況下，從用戶端到目標伺服器的整個鏈路顯著包含以下幾個網路地區。關於網路地區的說明及對應地區的異常處理建議，請參閱以下內容。
用戶端本網
本地區域網路和本網供應商網路，如前文鏈路測試結果樣本圖中的地區A，該地區的異常可以分為兩種。
如果是用戶端本網相關節點出現異常，則需要對本網進行相應排查分析。
如果是本網供應商網路相關節點出現異常，則需要向當地電訊廠商反饋問題。
電訊廠商網路
電訊廠商網路，如前文鏈路測試結果樣本圖中的地區B，可能會經過多個骨幹網路。如果該地區出現異常，可以根據異常節點IP地址查詢該IP地址歸屬的電訊廠商，然後直接或通過阿里雲售後支援人員，向相應電訊廠商反饋問題。
目標伺服器本網
目標主機歸屬網路供應商網路，如前文鏈路測試結果樣本圖中的地區C，如果該地區出現異常，則需要向目標主機歸屬網路供應商反饋問題。
如果中間鏈路某些部分啟用了鏈路負載平衡，則mtr命令只會對首尾節點進行編號和探測統計。中間節點只會顯示相應的IP地址或網域名稱資訊。
指標分析思路
要對網路鏈路連通性或網路效能進行分析，可以基於Loss%（丟包率）、Avg（平均值）和 StDev（標準差）以及延遲指標來進行綜合分析判斷，以下介紹基於以上指標分析鏈路連通性的基本思路。
Loss%（丟包率）
任一節點的Loss%（丟包率）如果不為零，則說明這一跳網路可能存在問題。導致相應節點丟包的原因通常有如下兩種：
電訊廠商基於安全或效能需求，人為限制了節點的ICMP發送速率，導致丟包。
節點確實存在異常，導致丟包。此時您可以結合異常節點及其後續節點的丟包情況，來判定丟包原因：
如果隨後節點均沒有丟包，則通常說明異常節點丟包是由於電訊廠商策略限制所致。可以忽略相關丟包。如前文鏈路測試結果樣本圖中的第2跳所示。
如果隨後節點也出現丟包，則通常說明異常節點確實存在網路異常，導致丟包。如前文鏈路測試結果樣本圖中的第6跳所示。
如果隨後節點出現沒有丟包的節點和丟包的節點，即相應節點既存在策略限速，又存在網路異常。對於這種情況，如果異常節點及其後續節點連續出現丟包，而且各節點的丟包率不同，則通常以最後幾跳的丟包率為準。如前文鏈路測試結果樣本圖所示，在第 6、7、8、9跳均出現了丟包。所以，最終丟包情況，以第9跳的30.3%作為參考。
Avg（平均值）和 StDev（標準差）
由於鏈路抖動或其他因素的影響，節點的Best和Wrst值可能相差很大。而Avg（平均值）統計了自鏈路測試以來所有探測的平均值，所以能更好地反映出相應節點的網路品質。而StDev（標準差值）越高，則說明資料包在相應節點的延時值越不相同（越離散）。所以標準差值可用於協助判斷Avg是否真實反映了相應節點的網路品質。例如，如果標準差很大，說明資料包的延遲是不確定的。可能某些資料包延遲很小（例如25 ms），而另一些延遲卻很大（例如350 ms），但最終得到的平均延遲反而可能是正常的。所以此時Avg並不能很好的反映出實際的網路品質情況。
綜上，建議分析標準如下：
如果StDev值很高，則同步觀察相應節點的
Best和Wrst，來判斷相應節點是否存在異常。如果StDev值不高，則通過Avg來判斷相應節點是否存在異常。
說明StDev值高或者不高，並沒有具體的時間範圍標準，而需要根據同一節點其他列的延遲值大小來進行評估。例如，如果Avg為30ms，當StDev為25ms時，則認為是很高的偏差。而如果Avg為325ms，當StDev同樣為25ms時，反而認為是不高的偏差。
延遲
延遲跳變
如果在某一跳之後延遲陡增，則通常判斷該節點存在網路異常。如前文鏈路測試結果樣本圖所示，從第6跳之後的後續節點延遲陡增，則推斷是第6跳節點出現了網路異常。不過，高延遲並不一定完全意味著相應節點存在異常。如前文鏈路測試結果樣本圖所示，第6跳之後，雖然後續節點延遲陡增，但測試資料最終仍然正常到達了目的主機。所以，延遲大也有可能是在資料回包鏈路中引發的。所以，建議結合反向鏈路測試一併分析。
ICMP限速導致延遲增加
ICMP策略限速也可能會導致相應節點的延遲陡增，但後續節點通常會恢複正常。如前文鏈路測試結果樣本圖所示，第9跳有30%的丟包率，同時延遲也明顯陡增。但隨後節點的延遲馬上恢複了正常。所以判斷該節點的延遲陡增及丟包是由於策略限速所致。
樣本分析及結論
結合上述鏈路測試結果樣本圖及分析思路，可以得出如下結論。
在用戶端本網地區，2、6、7、8、9跳出現了丟包現象，但後續的3、4、5、10、11、15跳並未出現大量丟包，如果對應的業務網路請求並無異常，則可以判斷2、6、7、8、9跳的丟包可能是觸發了ICMP限速導致。
第4跳
Wrst值較高，但是Avg值不高，有可能是某一次探測時網路有波動或者裝置效能波動引發的瞬時網路鏈路波動。整條鏈路節點延遲平均值介於1.8 - 17.6之間，顯示整條鏈路網路延遲較低。
基於以上幾條分析結論，可以判斷執行個體中的網路鏈路正常。如果實際業務網路中確實存在網路波動，可以結合反向鏈路測試結果一併進行分析。
對網路結果分析的思路較為靈活，以上僅為指標分析的一些常見方法。在實際的網路結果分析中，您需要結合自身的實際情況進行綜合評估，以便得出準確的結論。如果單向網路鏈路測試無法提供明確的結論，您可以結合反向鏈路測試進行更深入的問題分析與定位。
常見鏈路異常情境
常見的鏈路異常情境將以在Linux作業系統上執行mtr命令為例進行說明。具體結果應以您實際作業系統和工具的返回結果為準。
目標主機網路設定不當
如下圖所示，資料包在目標地址出現了100%的丟包。初步看是資料包沒有到達，其實很有可能是目標伺服器相關安全性原則，例如防火牆、iptables等禁用了ICMP所致，導致目的主機無法發送任何應答。所以，該情境需要排查目標伺服器的安全性原則配置。
ICMP限速
如下圖所示，資料包在目標地址出現了100%的丟包。初步看是資料包沒有到達，其實很有可能是目標伺服器相關安全性原則，例如防火牆、iptables 、電訊廠商策略等禁用了ICMP所致，導致目的主機無法發送任何應答。所以，該情境需要排查目標伺服器的安全性原則配置，或結合反向MTR鏈路測試綜合分析。
鏈路中存在環路
如下圖所示，資料包在第5跳之後出現了迴圈跳轉，導致最終無法到達目標伺服器。這通常是由於電訊廠商相關節點路由配置異常，即鏈路中存在環路所致。所以，該情境需要聯絡相應節點歸屬電訊廠商處理。
鏈路中斷
如下圖所示，資料包在第4跳之後未能收到任何反饋，Loss%、Last、Avg、Best等指標均未顯示任何統計資料。這通常是由於相應節點的中斷所致。建議結合反向鏈路測試進行進一步確認。該情境需聯絡相應節點所屬的電訊廠商進行處理。
