Wireshark TS | 二谈 TCP 握手异常问题

前言

继续以一个实际案例来说下 TCP 握手问题，该数据包仍然来自于 Wireshark sharkfest 2017，一些简短但有趣的 TCP 跟踪文件中的又一个。当然产生 TCP 握手异常的原因会有很多，一方面限于自己所掌握的知识程度，某些方面的知识点掌握和理解上还是会有所欠缺，分析自然会不到位，另外一方面也是老生常谈的问题，大多数的实际案例并不是亲身经历，缺少基础环境以及进一步分析可能需要的资源，像是多点捕获的对比、正常和异常现象的对比、模拟测试复现异常验证等等，所以有时候我不得不成为一个“猜测”的工程师，模糊根因。

问题信息

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

λ capinfos Sample02.pcapng
File name:           Sample02.pcapng
File type:           Wireshark/... - pcapng
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: (not set)
Number of packets:   6
File size:           836 bytes
Data size:           350 bytes
Capture duration:    2.965008 seconds
First packet time:   2013-11-18 18:21:28.059918
Last packet time:    2013-11-18 18:21:31.024926
Data byte rate:      118 bytes/s
Data bit rate:       944 bits/s
Average packet size: 58.33 bytes
Average packet rate: 2 packets/s
SHA256:              00339945b951259fe0656842cda513f40dc412c816bda66578d4d06ce350314b
RIPEMD160:           c4bfddc2f23c078def1ad98153b56d41d20b012a
SHA1:                dd148ec87dc6b9714fc6dac5c583e4ffcc2ea4e5
Strict time order:   True
Capture application: Sanitized by TraceWrangler v0.6.4 build 806
Number of interfaces in file: 1
Interface #0 info:
                     Name = \Device\NPF_{C09F8401-EC02-4BA6-9EA3-C9B992ECC7CF}
                     Encapsulation = Ethernet (1 - ether)
                     Capture length = 65535
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Time resolution = 0x06
                     Operating system = Windows XP Service Pack 3, build 2600
                     Number of stat entries = 0
                     Number of packets = 6

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

数据包数量并不多，仅有 6 个，捕获持续时间为约 3 秒，平均速率 944 bits/s，在 Win XP 上通过 Wireshark 捕获，并经过 TraceWrangler 匿名化软件所处理，其他并没有什么特别的地方。

关于 TraceWrangler 匿名化软件简介，可以查看之前的文章《Wireshark 提示和技巧 | 如何匿名化数据包》

专家信息如下，同样因数据包很少，也没有些特别的提示，仅仅有一条 Warning RST 信息。

问题分析

展开完整的数据包文件信息，如下

数据包 No.1-2

1. ARP 请求和 ARP 响应，从 Info 信息上也可以看出是之后的客户端 192.168.0.1 请求服务器端 192.168.0.101 的 mac 地址；
2. 比较特别的是间隔时间，有 49ms 之多，了解网络的同学可能会更加清楚，ARP 请求和响应是出现在同一网段内的，49ms 时延的距离，两者真的是离得很远了；当然也有可能是服务器端性能问题响应数据包慢，不完全否定，但是结合以下 TCP 三次握手的时延，并不作为可能原因；

3. 数据包是在客户端 192.168.0.1 上所捕获，因为 Length 为 42 字节，小于以太网数据帧最小长度 60 字节的要求。

关于如何判断捕获点的说明，请查看之前的文章《Wireshark 提示和技巧 | 捕获点之 TCP 三次握手》。

数据包 No.3-6

1. 数据包 No.3-4，为标准的 TCP 三次握手中的前两次，RTT 45ms ，MSS 1460 ，均支持 SACK ；
2. 数据包 No.5，正常来说应该是客户端 192.168.0.1 发送 TCP 三次握手中的最后一个 ACK，但是在这里却是客户端 192.168.0.1 在第一个 SYN 超时间隔 3s 后所发送的 SYN 重传包。这里就会比较奇怪了，首先客户端完全忽略了服务器的 SYN/ACK，而且如上所述数据包跟踪文件是在客户端本身上所捕获，所以问题的原因就指向了客户端本身，在系统或是网卡硬件某个层面丢弃了 SYN/ACK；
   而因为客户端忽略了 SYN/ACK，所以在大约 3s 之后客户端重传了 SYN，这个也没有问题，在 linux 系统上关于 SYN 的超时重传时间确实有 1 秒和 3 秒两种；
3. 数据包 No.6，是服务器 192.168.0.101 所发送的 RST 数据包。在这里服务器实现也会有些许问题，如果在 No.5 客户端 SYN 重传的情况下，服务器如果接收到这个重传包，正常情况下同样会响应一次 SYN/ACK，而不是响应 RST 数据包。
   甚至在某些情况下，客户端会在这个 SYN 重传数据包之后收到两个 SYN/ACK 数据包，这是为什么？因为服务器 SYN/ACK 也会有超时重传的设置，如果服务器在客户端所发送的 SYN 重传数据包到达之间，No.2 SYN/ACK 先超时了，那么服务器就会先重传发送一次 SYN/ACK , 紧接着客户端 SYN 重传数据包到来，又触发产生一次 SYN/ACK，所以最终客户端会再收到两个 SYN/ACK 数据包。

问题总结

综上所述，这个不成功连接的案例，并不只是一个不稳定的连接，包括客户端和服务器双方面都会有一些不同寻常的现象。

当然一方面是真的有问题，另一方面可能是不同系统内核实现不一样，进而产生的一些附加现象。甚至说在协议栈测试工具以及数据包编辑工具的存在下，这是否是一个真实的案例也说不好。

仅仅是 6 个数据包，带给我们的思考却很多很多。