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

前言

继续以一个实际案例来说下 TCP 握手问题，该数据包仍然来自于 Wireshark sharkfest 2017，一些简短但有趣的 TCP 跟踪文件中的又一个，或者说是最后一个了。可以说这些都是和 TCP 握手相关的连接问题，有兴趣的朋友可以私信，届时共享下相关数据包。

问题信息

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

λ capinfos Sample03.pcapng
File name:           Sample03.pcapng
File type:           Wireshark/... - pcapng
File encapsulation:  Ethernet
File timestamp precision:  nanoseconds (9)
Packet size limit:   file hdr: (not set)
Packet size limit:   inferred: 58 bytes
Number of packets:   1102
File size:           116 kB
Data size:           956 kB
Capture duration:    69.469164000 seconds
First packet time:   2015-11-27 18:51:55.682798700
Last packet time:    2015-11-27 18:53:05.151962700
Data byte rate:      13 kBps
Data bit rate:       110 kbps
Average packet size: 867.71 bytes
Average packet rate: 15 packets/s
SHA256:              e0156ab381f1646742ff1400782334c8cfd78e64cdabd1368607806b61711df9
RIPEMD160:           eb423fa44c99618044fbadf6a2783eebcd03af44
SHA1:                d2b1059f35308520ba69e8cd29f3bcd7db998d8c
Strict time order:   True
Capture application: Sanitized by TraceWrangler v0.3.1 build 511
Number of interfaces in file: 1
Interface #0 info:
                     Name = eth0
                     Encapsulation = Ethernet (1 - ether)
                     Speed = 1000000000
                     Capture length = 65535
                     Time precision = nanoseconds (9)
                     Time ticks per second = 1000000000
                     Time resolution = 0x09
                     Number of stat entries = 0
                     Number of packets = 1102

λ

推测通过 Wireshark 捕获，snaplen 截断 58 字节长度，数据包捕获数量相对比较多 1102 个，捕获持续时间为 69.5 秒，平均速率 110 kbps， 并经过 TraceWrangler 匿名化软件所处理。

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

专家信息如下，相对数据包总数量来说，告警信息很少，仅仅 1 条 RST 以及 1 条 ACKed segment that wasn’t captured 信息，初步看起来挺正常的。

问题分析

数据包数量较多，就不完整展开，通过 tcp.stream 输出可知总共有 3 条 TCP Stream。

λ tshark -r Sample03.pcapng -T fields -e tcp.stream | sort | uniq
0
1
2

客户端 192.168.0.1 和服务器 10.10.10.1 交互的三条 TCP 流信息，其中 TCP Stream 2 稍显奇怪，仅仅只有 3 个数据包，同时这三条流中客户端 192.168.0.1 的源端口均为 24426 ，这是其中的一个疑点。

TCP Stream 0

首先从 TCP Stream 0 看起，整个遍历下来，是一次完整的 TCP 交互会话。其中在 Packet Details 中 TCP 会话完整性信息为 Conversation completeness：Complete，WITH_DATA（31) ，这说明 tcp.completeness 字段值为 31，如下：

• 1 : SYN
• 2 : SYN-ACK
• 4 : ACK
• 8 : DATA
• 16 : FIN
• 32 : RST

1 + 2 + 4 + 8 + 16 = 31 ，也就是 SYN + SYN-ACK + ACK + DATA + FIN 的值，说明 TCP Stream 0 是一个带有 Data 的完整 TCP 会话，从 TCP 三次握手，到中间数据传输，再到最后的 TCP 四次挥手。

关于 TCP 会话完整性分析介绍 以及 tcp.completeness 的显示过滤表达式使用方法，可见之前的文章 《Wireshark 提示和技巧 | TCP 会话完整性分析》

TCP Stream 1

在 TCP Stream 0 经历四次挥手后，客户端之后以同样源端口 24426 发起的 TCP Stream 1 发生了问题，服务器 10.10.10.1 回复了一个奇怪的 ACK，提示 TCP ACKed unseen segment 信息，客户端直接以 RST 结束了连接。

具体发生了什么？ 转向 TCP 详细视图来一探究竟，分析如下：

1. No.1040 - No.1043 为 TCP Stream 0 的四次挥手过程；

2. 在 16s 之后，TCP Stream 1 客户端 No.1044 SYN 发出，服务器响应了一个 ACK=158049099，乍看之下感觉 Num 158049099 出现的莫名其妙，但实际需要注意的是，Wireshark 默认的是 TCP 相对序列号，而不是绝对序列号。关闭 TCP Relative sequence numbers 选项后的信息如下

之前的相对序列号 158049099 ，实际上是绝对序列号 2430890842 相对于 2272841743 的差值，而真正的这个 ACK Num 2430890842 的由来却是延续于 Stream 0 。

熟悉 TCP 四次挥手的同学应该会明白，在 TCP Stream 0 中 No.1040 也就是服务器首先发出的 FIN ，在 No.1043 服务器最后一个ACK 之后，服务器该连接会进入 TIME_WAIT 状态，也就是会等待 2MSL 的时间才最终 CLOSED，但是在这个 2MSL 的时间内，客户端正好又以同样的源端口 24426 发起了新连接，对于服务器来说自然是匹配到了老连接信息，因此回复一个 ACK=2430890842 的数据包，客户端在收到之后，判断是属于窗口之外的异常数据包，以一个 RST 结束 Stream 1。当然这是对客户端来说，同时这个 RST 实际上也结束了服务器 TCP Stream 0 的连接。

3. 所以在 25s 之后，客户端 TCP Stream 2 No.1047 SYN 继续发出，虽然还是同样的源端口 24426 ，但是此时服务器的 TCP Sream 0 连接已经关闭再无相关信息了，所以 TCP Stream 2 完成了正常的又一次三次握手过程后，继续愉快的进行数据传输了。

No.1044 SYN 相距 No.1043 的时间仅为 16.49s ，仍处于 2MSL 时间范围内。虽然 No.1047 SYN 相距 No.1043 的时间为 42.45s，看起来仍是在 2MSL 时间范围内 ，为什么这次成功了？实际上是 No.1046 这个 RST 所带来的结果。

RFC 793 中规定 MSL 为 2 分钟,实际应用中常用的是 30 秒, 1 分钟和 2 分钟等, 2MSL 即两倍的 MSL 。

问题总结

关于 TCP TIME_WAIT 和 2MSL 的基础知识点，本篇并未详细展开，实际环境中 TIME_WAIT 状态对于服务器来说还是一个挺常见的现象，导致的原因也会有很多，后续有机会会再展开分析。