查看网站点击量互联网广告平台有哪些

前言

在之前的《虚假的 TCP Spurious Retransmission》文章中曾提到一个错误判断为 TCP Spurious Retransmission，实际为 TCP Out-Of-Order 的案例，本次继续探讨一个虚假的 TCP Spurious Retransmission 案例。

问题背景

TCP Spurious Retransmission ，Wireshark TCP 分析标志位的一种，文档定义如下：

Checks for a retransmission based on analysis data in the reverse direction. Set when all of the following are true:The SYN or FIN flag is set.
This is not a keepalive packet.
The segment length is greater than zero.
Data for this flow has been acknowledged. That is, the last-seen acknowledgment number has been set.
The next sequence number is less than or equal to the last-seen acknowledgment number.Supersedes “Fast Retransmission”, “Out-Of-Order”, and “Retransmission”.

简单来说，是在数据包跟踪文件中已经被 ACK 确认过的数据分段，又再一次被重传发送，那么这个重传的数据分段会被标记为 [TCP Spurious Retransmission]。

本案例所说的虚假的 [TCP Spurious Retransmission]，虽然也指的是 Wireshark 判断错误，但真实的问题并不是 Wireshark 所产生。

问题信息

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

λ capinfos "SR 02.pcapng"
File name:           SR 02.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:   20
File size:           2304 bytes
Data size:           15 kB
Capture duration:    0.135371488 seconds
First packet time:   2023-05-08 09:30:00.473685315
Last packet time:    2023-05-08 09:30:00.609056803
Data byte rate:      111 kBps
Data bit rate:       892 kbps
Average packet size: 755.00 bytes
Average packet rate: 147 packets/s
SHA256:              a57b14efacc0da4d119336110c39c193fb06d775632033e909cdae5c6c6b26e8
SHA1:                50b8444b92baaffcf5c29068717d258a99bc3893
Strict time order:   True
Capture application: Editcap (Wireshark) 4.0.5 (v4.0.5-0-ge556162d8da3)
Capture comment:     Sanitized by TraceWrangler v0.6.8 build 949
Number of interfaces in file: 1
Interface #0 info:Encapsulation = Ethernet (1 - ether)Capture length = 262144Time precision = nanoseconds (9)Time ticks per second = 1000000000Time resolution = 0x09Number of stat entries = 0Number of packets = 20

数据包文件通过 NPM 回溯分析下载，并根据 IP 通讯对做过特定过滤，且经过 TraceWrangler 匿名化软件处理。由于是截取数据包原因，所以捕获总时长为 0.135 秒多，数据包数量 20 个 ，传输速率 892 kbps。

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

专家信息如下，因为数据包特定截取且数量较少，所以仅有虚假重传、重传、ACK确认未捕获的分段等几个常见问题。

问题分析

展开数据包跟踪文件实际信息如下：

首先 79.194.24.85 为发送端，116.115.175.186 为接收端，接收端 No.11 ACK Num 为 7087 ，确认了 Seq Num 7087 之前的所有数据分段，但实际上因为发送端 No.10 的 Seq Num 5322 + Len 1460 < 7087，所以 No.11 标识为 [TCP ACKed unseen segment] 表明确认了未看到的数据段。

继续往下看，由于 No.11 ACK Num 为 7087，所以 No.12 Seq Num 6782 + Len 305 = 7087，疑似又重传了一遍，因此符合判断条件，标识为 [TCP Spurious Retransmission] 。

好吧，一切看起来挺合理，但为什么又说是判断错误呢？想到上篇文章提到的凡事深想一层，干活多做一步，再瞅瞅 ip.id ，你会发现发送端的 ip.id 确实是顺序递增的，并没有出现上一个案例中发送端的数据段乱序情况。

但实际上更进一步的思考，你会发现不管是哪个抓包点（发送端、接收端或中间），又或是哪种乱序以及重传的场景，都不可能发生图示下的情况，ACK 确认数据分段在前，实际数据分段在后的情况。

那么问题是什么？实际问题仍是乱序，但仅仅是 No.11 和 No.12 两个数据包之间的乱序，修正后的数据包文件如下，可以看见一切恢复正常。

但是为什么会出现这样的情况，乱序的数据段出现在了 ACK 确认之后。之后仍是在数据包文件中发现的端倪，发送端和接收端两个方向的 Vlan ID 不一致，该 Vlan ID 是通过镜像在 TAP 上标记，由此推断出可能造成乱序的原因是由于取自两个镜像会话，再经过 TAP 采集，最终到真正数据包被捕获时，数据包到达的顺序可能就会发生一定乱序，当然时间差距会看起来很小，本案例也就在1微秒左右。

问题总结

所以仅仅是捕获数据包的问题，实际的生产交互完全不会有这样的问题，因此类似这样的案例学习了解原因即可，也就完全没必要在 Wireshark 中手动修改该重传数据包为乱序，没有意义。