問題背景

網(wǎng)絡(luò)路徑不一致，或者說是網(wǎng)絡(luò)路徑來回不一致，再專業(yè)點可以說是網(wǎng)絡(luò)路徑不對稱，以上種種說法，做網(wǎng)絡(luò)方向的工程師肯定會更清楚些，用簡單的描述就是：

A 與 B 通訊場景，C 和 D 代表中間路徑可能存在的 N 個不同設(shè)備
A -> B 方向經(jīng)過了這樣的路徑，A — C — B
B -> A 方向經(jīng)過了這樣的路徑，B — D — A

以上網(wǎng)絡(luò)場景實際挺常見的，正常通訊沒有任何問題。

開篇明義，此案例就是一個上述場景下的丟包問題，原因已明，簡單分享下分析過程。

案例取自 SharkFest 2011《Packet Trace Whispering》

問題信息

數(shù)據(jù)包跟蹤文件基本信息如下：

λ capinfos Session-I1-Case2-pktloss.pcap
File name:           Session-I1-Case2-pktloss.pcap
File type:           Wireshark/tcpdump/... - pcap
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: 65535 bytes
Packet size limit:   inferred: 67 bytes
Number of packets:   71
File size:           5883 bytes
Data size:           13 kB
Capture duration:    11.639492 seconds
First packet time:   2011-02-18 04:26:07.508816
Last packet time:    2011-02-18 04:26:19.148308
Data byte rate:      1141 bytes/s
Data bit rate:       9135 bits/s
Average packet size: 187.20 bytes
Average packet rate: 6 packets/s
SHA256:              9c9e5cd8c6c2ef892efcd5d0302b17407b3943bbc02f6cc676d7457ade452e42
RIPEMD160:           de6dde6f5460acb52f399cc491c8cad81c0f5ab3
SHA1:                7e9de2c390e85874cc234a40c33c1f1e2cbc94ae
Strict time order:   True
Number of interfaces in file: 1
Interface #0 info:Encapsulation = Ethernet (1 - ether)Capture length = 65535Time precision = microseconds (6)Time ticks per second = 1000000Number of stat entries = 0Number of packets = 71

跟蹤文件在 linux 上通過 tcpdump 所捕獲，數(shù)據(jù)包數(shù)量并不多，只有 71 個，長度截斷為 67 字節(jié)，文件數(shù)據(jù)大小 13K 字節(jié)，捕獲時長 11.64 秒，平均速率 9135 bps。

統(tǒng)計會話信息中，可見 TCP 流 1 條，客戶端 192.168.1.1 -> 服務(wù)器端 10.10.10.10 。

專家信息如下，可以看到存在一定數(shù)量的（疑似）重傳和（疑似）虛假重傳現(xiàn)象，符合丟包現(xiàn)象。

問題分析

展開數(shù)據(jù)包跟蹤文件數(shù)據(jù)包詳情如下，

可以看出 TCP Stream 0 并沒有捕獲到 TCP 三次握手階段的數(shù)據(jù)包，但通過 TTL 字段值 128 可判斷出捕獲點在服務(wù)器端上或者靠近服務(wù)器端的地方，而 RTT 約為 0.1ms ，并且數(shù)據(jù)傳輸?shù)囊?guī)律是一個數(shù)據(jù)分段一個 ACK 確認不斷交互。

通過點選右下黑色位置，可直接快速跳轉(zhuǎn)到問題所在，可見 TCP 重傳和疑似重傳等問題。

也可以通過以下顯示過濾表達式，快速篩選 TCP 分析中的異常問題，這也是比較常用的技巧。

tcp.analysis.flags

可以看到總共有 10 個匹配數(shù)據(jù)包，包括來自于服務(wù)器端 10.10.10.10 的 TCP 重傳，以及來自于客戶端 192.168.1.1 的 TCP 虛假重傳，為什么會有如此涇渭分明的重傳現(xiàn)象呢？

展開 TCP 詳細分析，主要如下：

1. 服務(wù)器端 10.10.10.10 的 TCP 重傳

可以看到包括 No.47-48 以及之前的數(shù)據(jù)包，均正常交互。但從 No.49 Seq 2904 開始，由于一直未收到 ACK ，在約 300ms 左右發(fā)生了超時重傳 No.50，之后同樣一直未收到 ACK，產(chǎn)生了不斷超時重傳現(xiàn)象，間隔 300ms、600ms、1.2s 、1.2s、1.2s 和 2.4s。

特殊的地方在于，每一次超時重傳的時候有時還會帶上新的數(shù)據(jù)分段，TCP Len 不斷變大，但同樣沒有收到任何確認。

2. 客戶端 192.168.1.1 的 TCP 虛假重傳

不同于最初一個數(shù)據(jù)分段一個 ACK 確認不斷交互的傳輸規(guī)律，經(jīng)過服務(wù)器 10.10.10.10 的連續(xù)單方向數(shù)據(jù)傳輸無響應(yīng)后，客戶端 192.168.1.1 在 No.58 發(fā)送了一個數(shù)據(jù)分段 Len 11 ，并且可以看到服務(wù)器端 10.10.10.10 正?；貜?fù)了 ACK 確認收到，但是在 200ms 后，客戶端 192.168.1.1 仍然產(chǎn)生了超時重傳現(xiàn)象，之后的現(xiàn)象依舊，不斷重傳，間隔 200ms、400ms、800ms 和 1.6s。

為什么是 TCP 虛假重傳？ 這是因為在數(shù)據(jù)包跟蹤文件中，有數(shù)據(jù)分段，也有 ACK 確認，所以 Wireshark 基于上下文綜合判斷，該重傳屬于 TCP 虛假重傳現(xiàn)象。

實際上再想到開篇提到的網(wǎng)絡(luò)路徑不一致問題，就可以明白整個過程。

1. 由于服務(wù)器端發(fā)送的數(shù)據(jù)分段無法正常收到 ACK 確認，因此產(chǎn)生了 TCP 超時重傳，注意這里丟失的是服務(wù)器端發(fā)送方向的數(shù)據(jù)分段；
2. 而客戶端 -> 服務(wù)器端傳輸方向，數(shù)據(jù)分段可以正常發(fā)送且能收到，但服務(wù)器端返回的 ACK 數(shù)據(jù)包同樣無法返回至客戶端，所以客戶端產(chǎn)生了 TCP 超時重傳，注意這里丟失的是服務(wù)器端發(fā)送方向的 ACK；
3. 因此根本原因出現(xiàn)在服務(wù)器端 -> 客戶端傳輸?shù)姆较?#xff0c;在某一個時點開始，傳輸?shù)娜魏螖?shù)據(jù)包均無法正常到達客戶端。

經(jīng)過長時間的不斷跟蹤，最后查明問題是在單向路徑上的一臺交換機引擎軟件 BUG 引起。

問題總結(jié)

我們可能無法確定根因，但數(shù)據(jù)包分析可以為我們指明正確的方向。