ping不通或丟包時如何進行鏈路測試？ -

當用戶端訪問目標伺服器或負載平衡，使用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命令查看更多參數說明。

選擇性參數	參數說明
`-r`或`-report`	以報告模式顯示輸出。
`-p`或`-split`	將每次鏈路跟蹤的結果分別列出來。
`-s`或`-psize`	指定ping資料包的大小。
`-n`或`-no-dns`	不對IP地址做網域名稱反解析。
`-a`或`-address`	設定發送資料包的IP地址。說明該參數用於主機存在多個IP地址的情境。
-4	只使用IPv4協議。
-6	只使用IPv6協議。

您也可以在mtr命令運行過程中，輸入如下參數來快速切換模式。

參數	參數說明
`？`或`h`	顯示協助菜單。
`d`	切換顯示模式。
`n`	啟用或禁用DNS網域名稱解析。
`u`	使用ICMP或UDP資料包進行探測。

MTR返回樣本

以執行mtr 目標IP地址命令為例，返回結果如下：

預設配置下，返回結果清單中各資料項目的說明如下。

參數	參數說明
Host	節點IP地址和網域名稱。您可以按`n`鍵切換顯示。
Loss%	節點丟包率。
Snt	已發送資料包數。預設值是10，可以通過參數`-c`指定。
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是否真實反應了相應節點的網路品質。例如，如果標準差很大，說明資料包的延遲是不確定的。可能某些資料包延遲很小（例如25 ms），而另一些延遲卻很大（例如350 ms），但最終得到的平均延遲反而可能是正常的。所以此時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%的丟包率，同時延遲也明顯陡增。但隨後節點的延遲馬上恢複了正常。所以判斷該節點的延遲陡增及丟包是由於策略限速所致。

常見鏈路異常情境

說明

常見鏈路異常情境以Linux作業系統上執行mtr命令為例進行說明，具體結果以您的實際作業系統和工具返回結果為準。

目標主機網路設定不當

如下圖所示，資料包在目標地址出現了100%的丟包。初步看是資料包沒有到達，其實很有可能是目標伺服器相關安全性原則，例如防火牆、iptables等禁用了ICMP所致，導致目的主機無法發送任何應答。所以，該情境需要排查目標伺服器的安全性原則配置。

ICMP限速

如下圖所示，資料包在第7跳出現100%丟包，而後續節點顯示資料包正常傳輸的情況。初步看是資料包沒有到達，其實很有可能是目標伺服器相關安全性原則，例如防火牆、iptables 、電訊廠商策略等禁用了ICMP所致，導致目的主機無法發送任何應答。所以，該情境需要排查目標伺服器的安全性原則配置，或結合反向MTR鏈路測試綜合分析。

鏈路中存在環路

如下圖所示，資料包在第5跳之後出現了迴圈跳轉，導致最終無法到達目標伺服器。這通常是由於電訊廠商相關節點路由配置異常，即鏈路中存在環路所致。所以，該情境需要聯絡相應節點歸屬電訊廠商處理。

鏈路中斷

如下圖所示，資料包在第4跳之後就無法收到任何反饋。這通常是由於相應節點中斷所致。建議結合反向鏈路測試做進一步確認。該情境需要聯絡相應節點歸屬電訊廠商處理。