TCP 三次握手的学问多之又多
前言
问题信息
λ capinfos Sample02.pcapngFile name: Sample02.pcapngFile type: Wireshark/... - pcapngFile encapsulation: EthernetFile timestamp precision: microseconds (6)Packet size limit: file hdr: (not set)Number of packets: 6File size: 836 bytesData size: 350 bytesCapture duration: 2.965008 secondsFirst packet time: 2013-11-18 18:21:28.059918Last packet time: 2013-11-18 18:21:31.024926Data byte rate: 118 bytes/sData bit rate: 944 bits/sAverage packet size: 58.33 bytesAverage packet rate: 2 packets/sSHA256: 00339945b951259fe0656842cda513f40dc412c816bda66578d4d06ce350314bRIPEMD160: c4bfddc2f23c078def1ad98153b56d41d20b012aSHA1: dd148ec87dc6b9714fc6dac5c583e4ffcc2ea4e5Strict time order: TrueCapture application: Sanitized by TraceWrangler v0.6.4 build 806Number of interfaces in file: 1Interface #0 info:Name = DeviceNPF_{C09F8401-EC02-4BA6-9EA3-C9B992ECC7CF}Encapsulation = Ethernet (1 - ether)Capture length = 65535Time precision = microseconds (6)Time ticks per second = 1000000Time resolution = 0x06Operating system = Windows XP Service Pack 3, build 2600Number of stat entries = 0Number of packets = 6
关于 TraceWrangler 匿名化软件简介，可以查看之前的文章。 7ACE，公众号：Echo ReplyWireshark 提示和技巧 | 如何匿名化数据包
问题分析
-
ARP 请求和 ARP 响应，从 Info 信息上也可以看出是之后的客户端 192.168.0.1 请求服务器端 192.168.0.101 的 mac 地址； -
比较特别的是间隔时间，有 49ms 之多，了解网络的同学可能会更加清楚，ARP 请求和响应是出现在同一网段内的，49ms 时延的距离，两者真的是离得很远了；当然也有可能是服务器端性能问题响应数据包慢，不完全否定，但是结合以下 TCP 三次握手的时延，并不作为可能原因；
-
数据包是在客户端 192.168.0.1 上所捕获，因为 Length 为 42 字节，小于以太网数据帧最小长度 60 字节的要求。
关于如何判断捕获点的说明，请查看之前的文章《捕获点之 TCP 三次握手》，哈哈 确实算本人写的很用心的一篇技巧文章。 7ACE，公众号：Echo ReplyWireshark 提示和技巧 | 捕获点之 TCP 三次握手
-
数据包 No.3-4，为标准的 TCP 三次握手中的前两次，RTT 45ms ，MSS 1460 ，均支持 SACK ； -
数据包 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 秒两种； -
数据包 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 数据包。
问题总结
往期推荐
原文始发于微信公众号（Echo Reply）：Wireshark TS | 二谈 TCP 握手异常问题
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论