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

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

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

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

HS-01


问题分析

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

HS-02

数据包 No.1-2

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

HS-03

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

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


数据包 No.3-6

HS-04

  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 个数据包,带给我们的思考却很多很多。

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值