問(wèn)題背景

網(wǎng)絡(luò)路徑不一致，或者說(shuō)是網(wǎng)絡(luò)路徑來(lái)回不一致，再專(zhuān)業(yè)點(diǎn)可以說(shuō)是網(wǎng)絡(luò)路徑不對(duì)稱(chēng)，以上種種說(shuō)法，做網(wǎng)絡(luò)方向的工程師肯定會(huì)更清楚些，用簡(jiǎn)單的描述就是：

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

以上網(wǎng)絡(luò)場(chǎng)景實(shí)際挺常見(jiàn)的，正常通訊沒(méi)有任何問(wèn)題。

開(kāi)篇明義，此案例就是一個(gè)上述場(chǎng)景下的丟包問(wèn)題，原因已明，簡(jiǎn)單分享下分析過(guò)程。

案例取自 SharkFest 2011《Packet Trace Whispering》

問(wèn)題信息

數(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 上通過(guò) tcpdump 所捕獲，數(shù)據(jù)包數(shù)量并不多，只有 71 個(gè)，長(zhǎng)度截?cái)酁?67 字節(jié)，文件數(shù)據(jù)大小 13K 字節(jié)，捕獲時(shí)長(zhǎng) 11.64 秒，平均速率 9135 bps。

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

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

問(wèn)題分析

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

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

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

也可以通過(guò)以下顯示過(guò)濾表達(dá)式，快速篩選 TCP 分析中的異常問(wèn)題，這也是比較常用的技巧。

tcp.analysis.flags

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

展開(kāi) TCP 詳細(xì)分析，主要如下：

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

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

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

2. 客戶(hù)端 192.168.1.1 的 TCP 虛假重傳

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

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

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

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

經(jīng)過(guò)長(zhǎng)時(shí)間的不斷跟蹤，最后查明問(wèn)題是在單向路徑上的一臺(tái)交換機(jī)引擎軟件 BUG 引起。

問(wèn)題總結(jié)

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