當客戶端訪問目標服務器或負載均衡，使用ping命令測試出現丟包或網絡不通時，可以通過鏈路測試工具進行鏈路測試來判斷問題來源。本文介紹如何使用鏈路測試工具進行鏈路測試。
鏈路測試流程
通常情況下，鏈路測試流程如下圖所示。
鏈路測試流程說明如下：
獲取本地網絡對應公網IP地址。
在客戶端本地網絡上，訪問IP地址查詢等網站，獲取本地網絡對應的公網IP地址。
正向鏈路測試（ping和mtr）。
從客戶端向目標服務器做ping和mtr鏈路測試。
ping：從客戶端向目標服務器域名或IP地址做持續的ping測試時，建議至少測試100個數據包，記錄測試結果。
mtr：根據客戶端操作系統環境的不同，在Windows操作系統上使用WinMTR或在Linux操作系統上執行mtr命令，設置測試目的地址為目標服務器域名或IP地址，然后進行鏈路測試，記錄測試結果。
反向鏈路測試（ping和mtr）。
進入目標服務器操作系統內部向客戶端做反向ping和mtr鏈路測試。
ping：從目標服務器向客戶端IP地址做持續的ping測試時，建議至少測試100個數據包，記錄測試結果。
mtr：根據目標服務器操作系統環境的不同，在Windows操作系統上使用WinMTR或在Linux操作系統上執行mtr命令，設置測試目的地址為客戶端IP地址，然后進行鏈路測試，記錄測試結果。
測試結果分析。
對測試結果進行分析，相關參數說明請參見鏈路測試結果說明。確認異常節點后，訪問IP地址查詢等網站查詢并獲取相應節點歸屬的運營商及網絡，解決方案如下：
如果是客戶端本地網絡相關節點出現異常，則需要對本地網絡進行相應排查分析。
如果是運營商相關節點出現異常，則需要直接聯系運營商，或聯系阿里云售后技術支持向相應運營商反饋問題。
進行鏈路測試
Linux操作系統
MTR是一款網絡診斷工具，其將ping和traceroute的功能合并，相對于traceroute只會做一次鏈路跟蹤測試，mtr會對鏈路上的相關節點做持續探測并給出相應的統計信息。因此，mtr能避免節點波動對測試結果的影響，所以其測試結果更正確，建議優先使用。
MTR（推薦）
安裝mtr
sudo yum install mtr使用MTR
mtr命令格式如下：
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命令運行過程中，輸入如下參數來快速切換模式。
參數 | 參數說明 |
| 顯示幫助菜單。 |
| 切換顯示模式。 |
| 啟用或禁用DNS域名解析。 |
| 使用ICMP或UDP數據包進行探測。 |
MTR返回示例
以執行mtr 目標IP地址命令為例，返回結果如下：
默認配置下，返回結果列表中各數據項的說明如下。
參數 | 參數說明 |
Host | 節點IP地址和域名。您可以按 |
Loss% | 節點丟包率。 |
Snt | 已發送數據包數。默認值是10，可以通過參數 |
Last | 最近一次的探測延遲值。 |
Avg | 探測延遲的平均值。 |
Best | 探測延遲的最小值。 |
Wrst | 探測延遲的最大值。 |
StDev | 標準偏差。該值越大說明相應節點越不穩定。 |
traceroute
安裝traceroute
sudo yum install traceroute使用traceroute
traceroute命令格式如下：
traceroute [-I] [ -m Max_ttl ] [ -n ] [ -p Port ] [ -q Nqueries ] [ -r ] [ -s SRC_Addr ] [ -t TypeOfService ] [ -f flow ] [ -v ] [ -w WaitTime ] Host [ PacketSize ]常見的可選參數說明如下表所示，您也可以通過man traceroute命令查看更多參數說明。
可選參數 | 參數說明 |
-d | 使用Socket層級的排錯功能。 |
-f | 設置第一個檢測數據包的存活數值TTL的大小。 |
-F | 設置不要分段標識。 |
-g | 設置來源路由網關，最多可設置8個。 |
-i | 主機有多個網卡時，使用指定的網卡發送數據包。 |
-I | 使用ICMP數據包替代UDP數據包進行探測。 |
-m | 設置檢測數據包的最大存活數值TTL的大小。 |
-n | 直接使用IP地址而非主機名稱（禁用DNS反查）。 |
-p | 設置UDP傳輸協議的通信端口。 |
-r | 忽略普通的Routing Table，直接將數據包發送到目標主機上。 |
-s | 設置本地主機發送數據包的IP地址。 |
-t | 設置檢測數據包的TOS數值。 |
-v | 詳細顯示指令的執行過程。 |
-w | 設置等待遠端主機回包時間。 |
-x | 開啟或關閉數據包的正確性檢驗。 |
traceroute返回示例
以執行traceroute -I 目標IP地址命令為例，返回結果如下：
Windows操作系統
WinMTR是mtr工具在Windows環境下的圖形化實現，但進行了功能簡化，只支持部分mtr的參數。WinMTR默認發送ICMP數據包進行探測，無法切換。相比tracert，WinMTR能避免節點波動對測試結果的影響，所以測試結果更正確。所以在WinMTR可用的情況下，建議優先使用WinMTR進行鏈路測試。
WinMTR（推薦）
安裝并使用WinMTR
下載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停止測試。
WinMTR返回示例
以測試目標服務器域名為例，返回示例如下：
默認配置下，返回結果中各數據項的說明如下：
參數 | 參數說明 |
Hostname | 節點IP地址和域名。 |
Nr | 節點編號。 |
Loss% | 節點丟包率。 |
Sent | 已發送的數據包數量。 |
Recv | 已成功接收的數據包數量。 |
Best | 節點延遲的最小值。 |
Avg | 節點延遲的平均值。 |
Worst | 節點延遲的最大值。 |
Last | 節點延遲的最后一次值。 |
StDev | 標準偏差。該值越大說明相應節點越不穩定。 |
tracert
tracert（Trace Route）是Windows系統自帶的網絡診斷命令行程序，用于跟蹤Internet協議（IP）數據包傳送到目標地址時經過的路徑。
使用tracert
在Windows PowerShell或cmd命令行中執行tracert命令。
tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] [-R] [-S srcaddr] [-4] [-6] target_name參數 | 參數說明 |
-d | 不要將地址解析為主機名（禁用DNS反解）。 |
-h | maximum_hops，指定搜索目標地址時的最大躍點數。 |
-j | host-list，指定沿主機列表的松散源路由。 |
-w | timeout，等待每個回復的超時時間（以毫秒為單位）。 |
-R | 跟蹤往返行程路徑（僅適用于IPv6）。 |
-S | srcaddr，要使用的源地址（僅適用于IPv6）。 |
-4 | 強制使用IPv4。 |
-6 | 強制使用IPv6。 |
target_host | 目標主機域名或IP地址。 |
tracert返回示例
以執行tracert -d 目標IP地址命令為例，返回結果如下：
C:\> tracert -d 192.168.0.1
通過最多 30 個躍點跟蹤到 192.168.0.1 的路由
1 請求超時。
2 9 ms 3 ms 12 ms 192.168.XXX.XXX
3 4 ms 9 ms 2 ms 10.20.XXX.XXX
4 9 ms 2 ms 1 ms 10.35.XXX.XXX
5 11 ms 211.24.X.XX
6 3 ms 2 ms 2 ms 200.12.XXX.XXX
7 2 ms 2 ms 1 ms 42.28.XXX.XXX
8 32 ms 4 ms 3 ms 42.25.2XX.2XX
9 請求超時。
10 3 ms 2 ms 2 ms 通過最多 30 個躍點跟蹤到 192.168.0.1 的路由
跟蹤完成。鏈路測試結果說明
由于mtr命令有更高的準確性，本文以mtr命令測試結果為例，對鏈路測試結果的分析進行簡要說明。后續的說明，均以如下鏈路測試結果示例圖為基礎進行闡述。
網絡區域
通常情況下，從客戶端到目標服務器的整個鏈路，會顯著的包含如下區域：
客戶端本地網絡
本地局域網和本地網絡提供商網絡，如前文鏈路測試結果示例圖中的區域A，一般為前2~3個節點。如果該區域出現異常，如果是客戶端本地網絡相關節點出現異常，則需要對本地網絡進行相應排查分析。否則，如果是本地網絡提供商網絡相關節點出現異常，則需要向當地運營商反饋問題。
運營商網絡
運營商網絡，如前文鏈路測試結果示例圖中的區域B，一般有很多個節點，并且會經過很多個骨干網絡。如果該區域出現異常，可以根據異常節點IP地址查詢該IP地址歸屬的運營商，然后直接或通過阿里云售后技術支持，向相應運營商反饋問題。
目標服務器本地網絡
目標主機歸屬網絡提供商網絡，如前文鏈路測試結果示例圖中的區域C，一般為最后目標服務器IP地址前的2~3個節點。如果該區域出現異常，則需要向目標主機歸屬網絡提供商反饋問題。
鏈路負載均衡
如前文鏈路測試結果示例圖中的區域D。如果中間鏈路某些部分啟用了鏈路負載均衡，則mtr命令只會對首尾節點進行編號和探測統計。中間節點只會顯示相應的IP地址或域名信息。
Avg（平均值）和 StDev（標準偏差）
由于鏈路抖動或其他因素的影響，節點的Best和Wrst值可能相差很大。而Avg（平均值）統計了自鏈路測試以來所有探測的平均值，所以能更好的反應出相應節點的網絡質量。而StDev（標準偏差值）越高，則說明數據包在相應節點的延時值越不相同（越離散）。所以標準偏差值可用于協助判斷Avg是否真實反應了相應節點的網絡質量。例如，如果標準偏差很大，說明數據包的延遲是不確定的。可能某些數據包延遲很?。ɡ?5 ms），而另一些延遲卻很大（例如350 ms），但最終得到的平均延遲反而可能是正常的。所以此時Avg并不能很好的反應出實際的網絡質量情況。
綜上，建議分析標準如下：
如果StDev值很高，則同步觀察相應節點的Best和Wrst，來判斷相應節點是否存在異常。
如果StDev值不高，則通過Avg來判斷相應節點是否存在異常。
說明StDev值高或者不高，并沒有具體的時間范圍標準，而需要根據同一節點其他列的延遲值大小來進行評估。例如，如果Avg為30ms，當StDev為25ms時，則認為是很高的偏差。而如果Avg為325ms，當StDev同樣為25ms時，反而認為是不高的偏差。
Loss%（丟包率）
任一節點的Loss%（丟包率）如果不為零，則說明這一跳網絡可能存在問題。導致相應節點丟包的原因通常有如下兩種：
運營商基于安全或性能需求，人為限制了節點的ICMP發送速率，導致丟包。
節點確實存在異常，導致丟包。
您可以結合異常節點及其后續節點的丟包情況，來判定丟包原因：
如果隨后節點均沒有丟包，則通常說明異常節點丟包是由于運營商策略限制所致?？梢院雎韵嚓P丟包。如前文鏈路測試結果示例圖中的第2跳所示。
如果隨后節點也出現丟包，則通常說明異常節點確實存在網絡異常，導致丟包。如前文鏈路測試結果示例圖中的第5跳所示。
如果隨后節點出現沒有丟包的節點和丟包的節點，即相應節點既存在策略限速，又存在網絡異常。對于這種情況，如果異常節點及其后續節點連續出現丟包，而且各節點的丟包率不同，則通常以最后幾跳的丟包率為準。如前文鏈路測試結果示例圖所示，在第 5、6、7跳均出現了丟包。所以，最終丟包情況，以第7跳的40%作為參考。
延遲
延遲跳變
如果在某一跳之后延遲陡增，則通常判斷該節點存在網絡異常。如前文鏈路測試結果示例圖所示，從第5跳之后的后續節點延遲陡增，則推斷是第5跳節點出現了網絡異常。不過，高延遲并不一定完全意味著相應節點存在異常。如前文鏈路測試結果示例圖所示，第5跳之后，雖然后續節點延遲陡增，但測試數據最終仍然正常到達了目的主機。所以，延遲大也有可能是在數據回包鏈路中引發的。所以，建議結合反向鏈路測試一并分析。
ICMP限速導致延遲增加
ICMP策略限速也可能會導致相應節點的延遲陡增，但后續節點通常會恢復正常。如前文鏈路測試結果示例圖所示，第3跳有100%的丟包率，同時延遲也明顯陡增。但隨后節點的延遲馬上恢復了正常。所以判斷該節點的延遲陡增及丟包是由于策略限速所致。
常見鏈路異常場景
常見鏈路異常場景以Linux操作系統上執行mtr命令為例進行說明，具體結果以您的實際操作系統和工具返回結果為準。
目標主機網絡配置不當
如下圖所示，數據包在目標地址出現了100%的丟包。初步看是數據包沒有到達，其實很有可能是目標服務器相關安全策略，例如防火墻、iptables等禁用了ICMP所致，導致目的主機無法發送任何應答。所以，該場景需要排查目標服務器的安全策略配置。
ICMP限速
如下圖所示，數據包在第7跳出現100%丟包，而后續節點顯示數據包正常傳輸的情況。初步看是數據包沒有到達，其實很有可能是目標服務器相關安全策略，例如防火墻、iptables 、運營商策略等禁用了ICMP所致，導致目的主機無法發送任何應答。所以，該場景需要排查目標服務器的安全策略配置，或結合反向MTR鏈路測試綜合分析。
鏈路中存在環路
如下圖所示，數據包在第5跳之后出現了循環跳轉，導致最終無法到達目標服務器。這通常是由于運營商相關節點路由配置異常，即鏈路中存在環路所致。所以，該場景需要聯系相應節點歸屬運營商處理。
鏈路中斷
如下圖所示，數據包在第4跳之后就無法收到任何反饋。這通常是由于相應節點中斷所致。建議結合反向鏈路測試做進一步確認。該場景需要聯系相應節點歸屬運營商處理。
