Wireshark TS | TCP 握手异常问题 - 新鲜讯息

坚持问题导向

前言

关于网络协议分析，我们经常会接触一些各式各样的数据包跟踪文件，有标准协议报文用于研究的，有排查故障分析使用的等等。

就我个人来说，也总会从互联网收集一些数据包案例，有时会在这些跟踪文件中查找问题，试着找出一些看起来不太正常的东西，并尝试分析可能的影响。当然，很多时候由于多方面资源的缺失，部分跟踪文件的问题已无法得到一个明确的答案，但可以观察数据包的不同交互行为，尝试找到一个合理的解释。

问题信息

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

λ capinfos Sample01.pcapngFile name:           Sample01.pcapngFile type:           Wireshark/... - pcapngFile encapsulation:  EthernetFile timestamp precision:  microseconds (6)Packet size limit:   file hdr: (not set)Packet size limit:   inferred: 54 bytes - 59 bytes (range)Number of packets:   15File size:           1756 bytesData size:           1504 bytesCapture duration:    4.328701 secondsFirst packet time:   2013-01-22 07:09:21.023257Last packet time:    2013-01-22 07:09:25.351958Data byte rate:      347 bytes/sData bit rate:       2779 bits/sAverage packet size: 100.27 bytesAverage packet rate: 3 packets/sSHA256:              ea32270673ebc233e8229118bce6a8e522a4920d53fbe780a906f20f76e4ddd9RIPEMD160:           dfc99ad2ea5826ebf361ce9a376d11ef85628976SHA1:                9d11a1f96469a6e3002dcb4c21054e2bb542f950Strict time order:   TrueCapture application: Sanitized by TraceWrangler v0.6.4 build 806Number of interfaces in file: 1Interface #0 info:                     Name = DeviceNPF_{2EE03F8E-3C66-48E3-86B3-6AD1273BCD6B}                     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 = 15

数据包数量并不多，仅有 15 个，捕获持续时间为 4.3 秒，平均速率 2779 bit/s，在 Win XP 上通过 Wireshark 捕获，并经过 TraceWrangler 匿名化软件所处理。

这里比较特别的地方是 Packet size limit: inferred: 54 bytes - 59 bytes (range) ，通常来说根据 snaplen 做截断，应该是一个统一的数值，也就是所有的数据包捕获长度应该是一样的，而不是一个范围值，但确实也不排除有些数据包做过特殊处理。

专家信息如下，这其中也会有一些很奇怪的信息，包括 The non-SYN packet does contain a MSS option ，非 SYN 的数据包包含有 MSS 信息，感觉要么是一个错误的 TCP 协议栈实现，要么是人为伪造的数据包。

问题分析

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

首先查看捕获帧长度的问题，增加 Capture Length 列，对比可知在 No.7、No.9 和 No.10 均存在捕获长度小于实际帧长度的地方，并且有两个值，54 和 59 ，确实如 capinfos 的提示信息一样，Packet size limit: inferred: 54 bytes - 59 bytes (range) ，此处初步判断是人为编辑过数据包跟踪文件。

其次 Warning 问题 The non-SYN packet does contain a MSS option ，除了 No.1 - No.4 的 TCP 三次握手之外，确实在 No.5 和 No.6 也就是 Server 192.168.0.101 发送的两个 ACK 存在 MSS 1460 的信息，理论上来说，MSS 通告信息仅存在于 TCP 三次握手建立连接的环节。

如上所述，这并不是一个正常的 TCP 协议栈实现，结合捕获长度的问题，再加上是 sharkfest 的故障案例分析，我觉得大概率此跟踪文件是人为伪造的数据包，以做案例分析使用。

既然是案例分析，那么我们进一步分析是否还有其他的问题存在。

TCP 三次握手环节还存在此许问题，主要分析如下：

客户端 192.168.0.1 和服务器 192.168.0.101 的 TCP 三次握手实际由 No.2 - No.4 三个数据包完成，RTT 2ms。
No.1 由客户端 192.168.0.1 所发送的第一个 SYN，由于网络或者服务器的关系，服务器并没有正常接收。结合后面的交互，实际上可判断为服务器的问题，性能或者其他问题并没有回应 SYN/ACK；
No.2 为客户端 192.168.0.1 No.1 SYN 发送超时后，第一个重传包，重传超时时间为 3 秒；
No.3 由服务器 192.168.0.101 响应的 SYN/ACK，对应于 No.2 SYN，理论上 No.1 SYN 在网络上不应该存活这长时间，但这里存在一个 Win=0 的状态，意味着服务器此时接收窗口为 0；🤣 开局即空血
之后在 TCP 三次握手完成后，客户端也并没有一些主动的请求数据，而 No.5 服务器仍因为 Win = 0 零窗口问题，主动通知了一个 TCP ZeroWindow 消息，而在过了 1.3 秒之后，接收窗口才打开了部分，进行了 TCP Window Update Win = 2048 的通知消息。

问题总结

奇怪的数据包，有趣的案例，估摸只有数据包的创建者才知道如何创造或是得来的了吧，未知答案就不纠结了，下一个案例见~

往期推荐