當客戶端訪問目標服務器出現(xiàn) ping 丟包或 ping 不通時，可以通過 tracert 或 mtr 等工具進行鏈路測試來判斷問題來源。本文先介紹了進行鏈路測試的相關工具，然后對測試結果分析及測試步驟進行了說明。

根據(jù)操作系統(tǒng)類型的不同，鏈路測試所使用的工具也有所不同。分別簡要介紹如下。

Linux環(huán)境下鏈路測試工具介紹

traceroute 命令行工具

mtr 命令行工具(建議優(yōu)先使用)

traceroute命令行工具

traceroute 是幾乎所有 Linux 發(fā)行版本預裝的網(wǎng)絡測試工具，用于跟蹤 Internet 協(xié)議(IP)數(shù)據(jù)包傳送到目標地址時經(jīng)過的路徑。

traceroute 先發(fā)送具有小的最大存活時間值(Max_TTL)的 UDP 探測數(shù)據(jù)包，然后偵聽從網(wǎng)關開始的整個鏈路上的 ICMP TIME_EXCEEDED 響應。探測從 TTL=1 開始，TTL 值逐步增加，直至接收到ICMP PORT_UNREACHABLE 消息。ICMP PORT_UNREACHABLE 消息用于標識目標主機已經(jīng)被定位，或命令已經(jīng)達到允許跟蹤的最大 TTL 值。

traceroute 默認發(fā)送 UDP 數(shù)據(jù)包進行鏈路探測?？梢酝ㄟ^ -I 參數(shù)來指定發(fā)送 ICMP 數(shù)據(jù)包用于探測。

用法說明：

traceroute [-I] [ -m Max_ttl ] [ -n ] [ -p Port ] [ -q Nqueries ] [ -r ] [ -s SRC_Addr ] [  -t TypeOfService ] [ -f flow ] [ -v ] [  -w WaitTime ] Host [ PacketSize ]

示例輸出：

[root@centos ~]# traceroute -I 223.5.5.5traceroute to 223.5.5.5 (223.5.5.5), 30 hops max, 60 byte packets 1     2  192.168.17.20 (192.168.17.20)  3.965 ms  4.252 ms  4.531 ms 3  111.1.20.41 (111.1.20.41)  6.109 ms  6.574 ms  6.996 ms 4  111.1.34.197 (111.1.34.197)  2.407 ms  2.451 ms  2.533 ms 5  211.138.114.25 (211.138.114.25)  1.321 ms  1.285 ms  1.304 ms 6  211.138.114.70 (211.138.114.70)  2.417 ms 211.138.114.66 (211.138.114.66)  1.857 ms 211.138.114.70 (211.138.114.70)  2.002 ms 7  42.120.244.194 (42.120.244.194)  2.570 ms  2.536 ms 42.120.244.186 (42.120.244.186)  1.585 ms 8  42.120.244.246 (42.120.244.246)  2.706 ms  2.666 ms  2.437 ms 9    10  public1.alidns.com (223.5.5.5)  2.817 ms  2.676 ms  2.401 ms

常見可選參數(shù)說明：

· -d 使用Socket層級的排錯功能。

· -f 設置第一個檢測數(shù)據(jù)包的存活數(shù)值TTL的大小。

· -F 設置不要分段標識。

· -g 設置來源路由網(wǎng)關，最多可設置8個。

· -i 使用指定的網(wǎng)卡送出數(shù)據(jù)包。用于主機有多個網(wǎng)卡時。

· -I 使用ICMP數(shù)據(jù)包替代 UDP 數(shù)據(jù)包進行探測。

· -m 設置檢測數(shù)據(jù)包的最大存活數(shù)值TTL的大小。

· -n 直接使用IP地址而非主機名稱（禁用 DNS 反查）。

· -p 設置UDP傳輸協(xié)議的通信端口。

· -r 忽略普通的Routing Table，直接將數(shù)據(jù)包送到遠端主機上。

· -s 設置本地主機送出數(shù)據(jù)包的IP地址。

· -t 設置檢測數(shù)據(jù)包的TOS數(shù)值。

· -v 詳細顯示指令的執(zhí)行過程。

· -w 設置等待遠端主機回包時間。

· -x 開啟或關閉數(shù)據(jù)包的正確性檢驗。

 

mtr命令行工具

mtr （My traceroute）也是幾乎所有 Linux 發(fā)行版本預裝的網(wǎng)絡測試工具。他把 ping和 traceroute 的功能并入了同一個工具中，所以功能更強大。

mtr 默認發(fā)送 ICMP 數(shù)據(jù)包進行鏈路探測?？梢酝ㄟ^ -u 參數(shù)來指定使用 UDP 數(shù)據(jù)包用于探測。

相對于 traceroute 只會做一次鏈路跟蹤測試，mtr 會對鏈路上的相關節(jié)點做持續(xù)探測并給出相應的統(tǒng)計信息。所以，mtr能避免節(jié)點波動對測試結果的影響，所以其測試結果更正確，建議優(yōu)先使用。

用法說明：

mtr [-hvrctglspni46] [—help] [—version] [—report]                [—report-cycles=COUNT] [—curses] [—gtk]                [—raw] [—split] [—no-dns] [—address interface]                [—psize=bytes/-s bytes]                [—interval=SECONDS] HOSTNAME [PACKETSIZE]

示例輸出：

[root@centos ~]# mtr 223.5.5.5                                  My traceroute  [v0.75]mycentos6.6 (0.0.0.0)                                             Wed Jun 15 23:16:27 2016Keys:  Help   Display mode   Restart statistics   Order of fields   quit                                                  Packets               Pings Host                                           Loss%   Snt   Last   Avg  Best  Wrst StDev 1. ??? 2. 192.168.17.20                                0.0%     7   13.1   5.6   2.1  14.7   5.7 3. 111.1.20.41                                  0.0%     7    3.0  99.2   2.7 632.1 235.4 4. 111.1.34.197                                 0.0%     7    1.8   2.0   1.2   2.9   0.6 5. 211.138.114.25                               0.0%     6    0.9   4.7   0.9  13.9   5.8 6. 211.138.114.70                               0.0%     6    1.8  22.8   1.8  50.8  23.6    211.138.128.134    211.138.114.2    211.138.114.66 7. 42.120.244.186                               0.0%     6    1.4   1.6   1.3   1.8   0.2    42.120.244.198 8. 42.120.244.246                               0.0%     6    2.8   2.9   2.6   3.2   0.2    42.120.244.242 9. ???10. 223.5.5.5                                    0.0%     6    2.7   2.7   2.5   3.2   0.3

常見可選參數(shù)說明：

· -r 或 —report：以報告模式顯示輸出。

· -p 或 —split：將每次追蹤的結果分別列出來，而非如 —report統(tǒng)計整個結果。

· -s 或 —psize：指定ping數(shù)據(jù)包的大小。

· -n 或 —no-dns：不對IP地址做域名反解析。

· -a 或 —address：設置發(fā)送數(shù)據(jù)包的IP地址。用于主機有多個IP時。

· -4：只使用 IPv4 協(xié)議。

· -6：只使用 IPv6 協(xié)議。

另外，也可以在mtr運行過程中，輸入相應字母來快速切換模式，比如：

· ？或 h：顯示幫助菜單。

· d：切換顯示模式。

· n：切換啟用或禁用 DNS 域名解析。

· u：切換使用 ICMP或 UDP 數(shù)據(jù)包進行探測。

返回結果說明：

默認配置下，返回結果中各數(shù)據(jù)列的說明：

· 第一列（Host）：節(jié)點IP地址和域名。如前面所示，按n鍵可以切換顯示。

· 第二列（Loss%）：節(jié)點丟包率。

· 第三列（Snt）：每秒發(fā)送數(shù)據(jù)包數(shù)。默認值是10，可以通過參數(shù) -c 指定。

· 第四列（Last）：最近一次的探測延遲值。

· 第五、六、七列（Avg、Best、Wrst）：分別是探測延遲的平均值、最小值和最大值。

· 第八列（StDev）：標準偏差。越大說明相應節(jié)點越不穩(wěn)定。

 

Windows環(huán)境下鏈路測試工具介紹

TRACERT命令行工具

WinMTR工具（建議優(yōu)先使用）

TRACERT命令行工具

TRACERT (Trace Route) 是 Windows 自帶的網(wǎng)絡診斷命令行實用程序，用于跟蹤 Internet 協(xié)議 (IP) 數(shù)據(jù)包傳送到目標地址時經(jīng)過的路徑。 

TRACERT 通過向目標地址發(fā)送 ICMP 數(shù)據(jù)包來確定到目標地址的路由。在這些數(shù)據(jù)包中，TRACERT 使用了不同的 IP“生存期”(TTL) 值。由于要求沿途的路由器在轉發(fā)數(shù)據(jù)包前至少必須將 TTL 減少 1，因此 TTL 實際上相當于一個躍點計數(shù)器 (hop counter)。當某個數(shù)據(jù)包的 TTL 達到零 (0) 時，相應節(jié)點就會向源計算機發(fā)送一個 ICMP“超時”的消息。 

TRACERT 第一次發(fā)送 TTL 為 1 的數(shù)據(jù)包，并在每次后續(xù)傳輸時將 TTL 增加 1，直到目標地址響應或達到 TTL 的最大值。中間路由器發(fā)送回來的 ICMP“超時”消息中包含了相應節(jié)點的信息。

用法說明：

tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] [-R] [-S srcaddr] [-4] [-6] target_name

示例輸出：

C:\\> tracert -d 223.5.5.5通過最多 30 個躍點跟蹤到 223.5.5.5 的路由  1                          請求超時。  2     9 ms     3 ms    12 ms  192.168.17.20  3     4 ms     9 ms     2 ms  111.1.20.41  4     9 ms     2 ms     1 ms  111.1.34.197  5    11 ms                  211.140.0.57  6     3 ms     2 ms     2 ms  211.138.114.62  7     2 ms     2 ms     1 ms  42.120.244.190  8    32 ms     4 ms     3 ms  42.120.244.238  9                          請求超時。 10     3 ms     2 ms     2 ms  223.5.5.5跟蹤完成。

常見可選參數(shù)說明：

· -d：指定不將地址解析為主機名（禁用 DNS 反解）。

· -h：maximum_hops，指定搜索目標地址時的最大躍點數(shù)。

· -j： host-list，指定沿主機列表的松散源路由。

· -w：timeout，由每個回復的 timeout 指定的等待毫秒數(shù)。

· -R：跟蹤往返行程路徑(僅適用于 IPv6)。

· -S：srcaddr，要使用的源地址(僅適用于 IPv6)。

· -4：強制使用 IPv4。

· -6：強制使用 IPv6。

· target_host：目標主機域名或 IP 地址。

WinMTR工具

WinMTR 是 mtr 工具在 Windows 環(huán)境下的圖形化實現(xiàn)，但進行了功能簡化，只支持 mtr部分參數(shù)的調(diào)整設置。WinMTR 默認發(fā)送ICMP 數(shù)據(jù)包進行探測，無法切換。

WinMTR 可以從其官方網(wǎng)站下載獲取。

和 mtr 一樣，相比 tracert，WinMTR 能避免節(jié)點波動對測試結果的影響，所以測試結果更正確。所以，在 WinMTR 可用的情況下，建議優(yōu)先使用 WinMTR 進行鏈路測試。

用法說明：

WinMTR 無需安裝，直接解壓運行即可。操作方法非常簡單，說明如下：

1.如下圖所示，運行程序后，在Host字段輸入目標服務器域名或IP（注意前面不要包含空格）

2.點擊Start開始測試（開始測試后，相應按鈕變成了Stop）。

3.運行一段時間后，點擊Stop停止測試。

4.其他選項說明：

Copy Text to clipboard：將測試結果以文本格式復制到粘貼板。

Copy HTML to clipboard：將測試結果以 HTML 格式復制到粘貼板。

Export TEXT：將測試結果以文本格式導出到指定文件。

Export HTML：將測試結果以 HTML 格式導出到指定文件。

Options：可選參數(shù)，包括：

Interval（sec）：每次探測的間隔（過期）時間。默認為 1 秒。

Ping size(bytes)： ping 探測所使用的數(shù)據(jù)包大小，默認為 64 字節(jié)。、

Max hosts in LRU list： LRU 列表支持的最大主機數(shù)，默認值為 128。

Resolve names：通過反查 IP 以域名顯示相關節(jié)點。

返回結果說明：

默認配置下，返回結果中各數(shù)據(jù)列的說明：

· 第一列（Hostname）：節(jié)點 IP 或域名。

· 第二列（Nr）：節(jié)點編號。

· 第三列（Loss%）：節(jié)點丟包率。

· 第四列（Sent）：已發(fā)送的數(shù)據(jù)包數(shù)量。

· 第五列（Recv）：已成功接收的數(shù)據(jù)包數(shù)量。

· 第六、七、八、九列（Best 、Avg、Worst、Last）：分別是到相應節(jié)點延遲的最小值、平均值、最大值和最后一次值。

· 第八列（StDev）：標準偏差。越大說明相應節(jié)點越不穩(wěn)定。

 

鏈路測試結果分析簡要說明

由于 mtr（WinMTR）有更高的準確性。本文以其測試結果為例，對鏈路測試結果的分析進行簡要說明。

后續(xù)說明，以如下鏈路測試結果示例圖為基礎進行闡述：

對鏈路測試結果進行分析時，需要關注如下要點：

· 網(wǎng)絡區(qū)域

· 鏈路負載均衡

· 結合Avg（平均值）和 StDev（標準偏差）綜合判斷

· Loss%（丟包率）的判斷

· 關于延遲

網(wǎng)絡區(qū)域

正常情況下，從客戶端到目標服務器的整個鏈路，會顯著的包含如下區(qū)域：

· 客戶端本地網(wǎng)絡（本地局域網(wǎng)和本地網(wǎng)絡提供商網(wǎng)絡）：如前文鏈路測試結果示例圖中的區(qū)域 A。如果該區(qū)域出現(xiàn)異常，如果是客戶端本地網(wǎng)絡相關節(jié)點出現(xiàn)異常，則需要對本地網(wǎng)絡進行相應排查分析。否則，如果是本地網(wǎng)絡提供商網(wǎng)絡相關節(jié)點出現(xiàn)異常，則需要向當?shù)剡\營商反饋問題。

· 運營商骨干網(wǎng)絡：如前文鏈路測試結果示例圖中的區(qū)域 B。如果該區(qū)域出現(xiàn)異常，可以根據(jù)異常節(jié)點 IP 查詢歸屬運營商，然后直接向相應運營商反饋問題。

· 目標服務器本地網(wǎng)絡（目標主機歸屬網(wǎng)絡提供商網(wǎng)絡）: 如前文鏈路測試結果示例圖中的區(qū)域 C。如果該區(qū)域出現(xiàn)異常，則需要向目標主機歸屬網(wǎng)絡提供商反饋問題。

鏈路負載均衡

如前文鏈路測試結果示例圖中的區(qū)域 D 所示。如果中間鏈路某些部分啟用了鏈路負載均衡，則 mtr 只會對首尾節(jié)點進行編號和探測統(tǒng)計。中間節(jié)點只會顯示相應的 IP 或域名信息。

結合Avg（平均值）和StDev（標準偏差）綜合判斷

由于鏈路抖動或其它因素的影響，節(jié)點的 Best 和 Worst 值可能相差很大。而 Avg（平均值） 統(tǒng)計了自鏈路測試以來所有探測的平均值，所以能更好的反應出相應節(jié)點的網(wǎng)絡質(zhì)量。

而 StDev（標準偏差值）越高，則說明數(shù)據(jù)包在相應節(jié)點的延時值越不相同（越離散）。所以，標準偏差值可用于協(xié)助判斷Avg 是否真實反應了相應節(jié)點的網(wǎng)絡質(zhì)量。例如，如果標準偏差很大，說明數(shù)據(jù)包的延遲是不確定的?？赡苣承?shù)據(jù)包延遲很?。ɡ纾?5ms），而另一些延遲卻很大（例如：350ms），但最終得到的平均延遲反而可能是正常的。所以，此時 Avg 并不能很好的反應出實際的網(wǎng)絡質(zhì)量情況。

綜上，建議的分析標準是：

· 如果 StDev 很高，則同步觀察相應節(jié)點的 Best 和 Wrst，來判斷相應節(jié)點是否存在異常。

· 如果 StDev 不高，則通過 Avg來判斷相應節(jié)點是否存在異常。

注：上述 StDev  “高”或者“不高”，并沒有具體的時間范圍標準。而需要根據(jù)同一節(jié)點其它列的延遲值大小來進行相對評估。比如，如果 Avg 為 30ms，那么，當 StDev 為 25ms，則認為是很高的偏差。而如果 Avg 為 325ms，則同樣的StDev（25ms），反而認為是不高的偏差。

Loss%（丟包率）的判斷

任一節(jié)點的 Loss%（丟包率）如果不為零，則說明這一跳網(wǎng)絡可能存在問題。導致相應節(jié)點丟包的原因通常有兩種：

· 運營商基于安全或性能需求，人為限制了節(jié)點的 ICMP 發(fā)送速率，導致丟包。

· 節(jié)點確實存在異常，導致丟包。

可以結合異常節(jié)點及其后續(xù)節(jié)點的丟包情況，來判定丟包原因：

· 如果隨后節(jié)點均沒有丟包，則通常說明異常節(jié)點丟包是由于運營商策略限制所致。可以忽略相關丟包。如前文鏈路測試結果示例圖中的第 2 跳所示。

· 如果隨后節(jié)點也出現(xiàn)丟包，則通常說明異常節(jié)點確實存在網(wǎng)絡異常，導致丟包。如前文鏈路測試結果示例圖中的第 5 跳所示。

 另外，需要說明的是，前述兩種情況可能同時發(fā)生。即相應節(jié)點既存在策略限速，又存在網(wǎng)絡異常。對于這種情況，如果異常節(jié)點及其后續(xù)節(jié)點連續(xù)出現(xiàn)丟包，而且各節(jié)點的丟包率不同，則通常以最后幾跳的丟包率為準。如前文鏈路測試結果示例圖所示，在第 5、6、7跳均出現(xiàn)了丟包。所以，最終丟包情況，以第 7 跳的 40% 作為參考。

 

關于延遲

延遲跳變

如果在某一跳之后延遲明顯陡增，則通常判斷該節(jié)點存在網(wǎng)絡異常。如前文鏈路測試結果示例圖所示，從第 5 跳之后的后續(xù)節(jié)點延遲明顯陡增，則推斷是第 5 跳節(jié)點出現(xiàn)了網(wǎng)絡異常。

不過，高延遲并不一定完全意味著相應節(jié)點存在異常。如前文鏈路測試結果示例圖所示，第 5 跳之后，雖然后續(xù)節(jié)點延遲明顯陡增，但測試數(shù)據(jù)最終仍然正常到達了目的主機。所以，延遲大也有可能是在數(shù)據(jù)回包鏈路中引發(fā)的。所以，最好結合反向鏈路測試一并分析。

ICMP限速導致延遲增加

ICMP 策略限速也可能會導致相應節(jié)點的延遲陡增，但后續(xù)節(jié)點通常會恢復正常。如前文鏈路測試結果示例圖所示，第 3 跳有100% 的丟包率，同時延遲也明顯陡增。但隨后節(jié)點的延遲馬上恢復了正常。所以判斷該節(jié)點的延遲陡增及丟包是由于策略限速所致。

 

常見鏈路異常場景和測試報告

常見的鏈路異常場景及測試報告實例下如所示：

目標主機網(wǎng)絡配置不當

示例數(shù)據(jù)：

t@mycentos6 ~]# mtr —no-dns www.google.comMy traceroute  [v0.75]mycentos6.6 (0.0.0.0)                                             Wed Jun 15 19:06:29 2016Keys:  Help   Display mode   Restart statistics   Order of fields   quit                                                  Packets               Pings Host                                           Loss%   Snt   Last   Avg  Best  Wrst StDev 1. ??? 2. ??? 3. 111.1.20.41                                  0.0%     10  521.3  90.1   2.7 521.3 211.3 4. 111.1.34.209                                 0.0%     10    2.9   4.7   1.6  10.6   3.9 5. 211.138.126.29                              80.0%     10    3.0   3.0   3.0   3.0   0.0 6. 221.183.14.85                                0.0%     10    1.7   7.2   1.6  34.9  13.6 7. 221.183.10.5                                 0.0%     10    5.2   5.2   5.1   5.2   0.0    221.183.11.5 8. 221.183.23.26                                0.0%     10    5.3   5.2   5.1   5.3   0.1 9. 173.194.200.105                            100.0%     10    0.0   0.0   0.0   0.0   0.0

在該實例中，數(shù)據(jù)包在目標地址出現(xiàn)了100%的丟包。乍一看是數(shù)據(jù)包沒有到達，其實很有可能是目標服務器相關安全策略（比如防火墻、iptables 等）禁用了 ICMP 所致，導致目的主機無法發(fā)送任何應答。

所以，該場景需要排查目標服務器的安全策略配置。

ICMP限速

示例數(shù)據(jù)：

[root@mycentos6 ~]# mtr —no-dns www.google.comMy traceroute  [v0.75]mycentos6.6 (0.0.0.0)                                             Wed Jun 15 19:06:29 2016Keys:  Help   Display mode   Restart statistics   Order of fields   quit                                                  Packets               Pings Host                           Loss%   Snt   Last   Avg  Best  Wrst StDev1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.32. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.83. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.74. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.15. 72.14.233.56                 60.0%    10   27.2  25.3  23.1  26.4   2.96. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.27. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.38. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

在該示例中，在第 5 跳出現(xiàn)了明顯的丟包，但后續(xù)節(jié)點均未見異常。所以推斷是該節(jié)點 ICMP 限速所致。

該場景對最終客戶端到目標服務器的數(shù)據(jù)傳輸不會有影響，所以，分析的時候可以忽略。

環(huán)路

示例數(shù)據(jù)：

[root@mycentos6 ~]# mtr —no-dns www.google.comMy traceroute  [v0.75]mycentos6.6 (0.0.0.0)                                             Wed Jun 15 19:06:29 2016Keys:  Help   Display mode   Restart statistics   Order of fields   quit                                                  Packets               Pings Host                           Loss%   Snt   Last   Avg  Best  Wrst StDev1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.32. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.83. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.74. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.15. 72.14.233.56                  0.0%    10    0.0   0.0   0.0   0.0   0.06. 72.14.233.57                  0.0%    10    0.0   0.0   0.0   0.0   0.07. 72.14.233.56                  0.0%    10    0.0   0.0   0.0   0.0   0.08. 72.14.233.57                  0.0%    10    0.0   0.0   0.0   0.0   0.09 ???                            0.0%    10    0.0   0.0   0.0   0.0   0.0

在該示例中，數(shù)據(jù)包在第 4 跳之后就無法收到任何反饋。這通常是由于相應節(jié)點中斷所致。建議結合反向鏈路測試做進一步確認。

該場景需要聯(lián)系相應節(jié)點歸屬運營商處理。