问题背景

网络路径不一致，或者说是网络路径来回不一致，再专业点可以说是网络路径不对称，以上种种说法，做网络方向的工程师肯定会更清楚些，用简单的描述就是：

A 与 B 通讯场景，C 和 D 代表中间路径可能存在的 N 个不同设备
A -> B 方向经过了这样的路径，A — C — B
B -> A 方向经过了这样的路径，B — D — A

以上网络场景实际挺常见的，正常通讯没有任何问题。

开篇明义，此案例就是一个上述场景下的丢包问题，原因已明，简单分享下分析过程。

案例取自 SharkFest 2011《Packet Trace Whispering》

问题信息

数据包跟踪文件基本信息如下：

λ 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 所捕获，数据包数量并不多，只有 71 个，长度截断为 67 字节，文件数据大小 13K 字节，捕获时长 11.64 秒，平均速率 9135 bps。

统计会话信息中，可见 TCP 流 1 条，客户端 192.168.1.1 -> 服务器端 10.10.10.10 。

专家信息如下，可以看到存在一定数量的（疑似）重传和（疑似）虚假重传现象，符合丢包现象。

问题分析

展开数据包跟踪文件数据包详情如下，

可以看出 TCP Stream 0 并没有捕获到 TCP 三次握手阶段的数据包，但通过 TTL 字段值 128 可判断出捕获点在服务器端上或者靠近服务器端的地方，而 RTT 约为 0.1ms ，并且数据传输的规律是一个数据分段一个 ACK 确认不断交互。

通过点选右下黑色位置，可直接快速跳转到问题所在，可见 TCP 重传和疑似重传等问题。

也可以通过以下显示过滤表达式，快速筛选 TCP 分析中的异常问题，这也是比较常用的技巧。

tcp.analysis.flags

可以看到总共有 10 个匹配数据包，包括来自于服务器端 10.10.10.10 的 TCP 重传，以及来自于客户端 192.168.1.1 的 TCP 虚假重传，为什么会有如此泾渭分明的重传现象呢？

展开 TCP 详细分析，主要如下：

1. 服务器端 10.10.10.10 的 TCP 重传

可以看到包括 No.47-48 以及之前的数据包，均正常交互。但从 No.49 Seq 2904 开始，由于一直未收到 ACK ，在约 300ms 左右发生了超时重传 No.50，之后同样一直未收到 ACK，产生了不断超时重传现象，间隔 300ms、600ms、1.2s 、1.2s、1.2s 和 2.4s。

特殊的地方在于，每一次超时重传的时候有时还会带上新的数据分段，TCP Len 不断变大，但同样没有收到任何确认。

2. 客户端 192.168.1.1 的 TCP 虚假重传

不同于最初一个数据分段一个 ACK 确认不断交互的传输规律，经过服务器 10.10.10.10 的连续单方向数据传输无响应后，客户端 192.168.1.1 在 No.58 发送了一个数据分段 Len 11 ，并且可以看到服务器端 10.10.10.10 正常回复了 ACK 确认收到，但是在 200ms 后，客户端 192.168.1.1 仍然产生了超时重传现象，之后的现象依旧，不断重传，间隔 200ms、400ms、800ms 和 1.6s。

为什么是 TCP 虚假重传？ 这是因为在数据包跟踪文件中，有数据分段，也有 ACK 确认，所以 Wireshark 基于上下文综合判断，该重传属于 TCP 虚假重传现象。

实际上再想到开篇提到的网络路径不一致问题，就可以明白整个过程。

1. 由于服务器端发送的数据分段无法正常收到 ACK 确认，因此产生了 TCP 超时重传，注意这里丢失的是服务器端发送方向的数据分段；
2. 而客户端 -> 服务器端传输方向，数据分段可以正常发送且能收到，但服务器端返回的 ACK 数据包同样无法返回至客户端，所以客户端产生了 TCP 超时重传，注意这里丢失的是服务器端发送方向的 ACK；
3. 因此根本原因出现在服务器端 -> 客户端传输的方向，在某一个时点开始，传输的任何数据包均无法正常到达客户端。

经过长时间的不断跟踪，最后查明问题是在单向路径上的一台交换机引擎软件 BUG 引起。

问题总结

我们可能无法确定根因，但数据包分析可以为我们指明正确的方向。