这是一个创建于 366 天前的主题，其中的信息可能已经有所发展或是发生改变。
事情是这样, 我发现 tcp 实际的 payload 长度和握手时协商的 MSS 长度多出很多.
按理来说根据不同的路由环境 segment 的长度比 mss 小可以理解,但是比 mss 大这就有点诡异了
下图时我的问题发生现场, 图 1 确认 mss 长度(图片有点模糊 显示的是 1357), 图 2 中 192.168.8.104 发送的 tcp segment 却比 mss 大很多
图 2 中的 segment 长度正好是 mss 的两倍 但在别的 frame 中也能找到非整数倍的 segment
我想知道的是 wireshark 是如何确认一个 tcp frame 是否为 segment 一开始以为是通过 mss 长度但发现这并不可靠, 也有很多特别小的 segment. 是通过应用层?
第 1 条附言 2024-10-09 10:56:12 +08:00
 | 1 turi 2024-10-09 09:17:33 +08:00 tcp tso |
 | 2 quanyajian 2024-10-09 09:33:03 +08:00 看你的第二个握手包 SYN-ACK ，里面应该也有一个 MSS 。 |
 | 3 sankooc OP @quanyajian 第二个 mss 是 1460 也跟 tcp 的 payload 相差很大 |
| 4 sankooc OP @turi 那能理解为 NIC 会通过网络情况会自动分包? 那 wireshark 分析的时候是如何判断出这些包是 segment 呢? 主要我最近做一个类似 wireshark 的工具 现在卡在合并应用层数据 |
| 5 quanyajian 2024-10-09 09:54:05 +08:00 把 pcap 文件贴出来看看 |
| 6 quanyajian 2024-10-09 09:56:12 +08:00 @sankooc 你应该是要做 tcp 重组，我这边用的 gopacket 实现的。 |
 | 7 swananan 2024-10-09 10:01:52 +08:00 抓包是在 网卡 tso 生效之前，所以还是大于 mtu 的报文，然后也符合 tcp 的格式，所以 wireshark 能够正常解析。 你要是在对端抓包，应该就是 网卡 tso 切分后的报文。 |
| 8 sankooc OP @quanyajian pcap 附上了 这个包我研究一下 |
| 9 sankooc OP @swananan 你是说通过 pmtud? 但是 segment 的大小应该是取 mtu 和 mss 的最小值 而且大于 mss 的 tcp 包并非都是 segment |
 | 10 ccsexyz 2024-10-09 12:20:49 +08:00 搜索一下关键词 TCP GRO/GSO |
| 11 swananan 2024-10-09 14:02:40 +08:00 @sankooc 我不是这个意思，和 mtu 发现没关系。我意思是用了 tso 或者 gso 这种手段，那么抓包看到的 mtu 就不准了。因为这些手段都是在 libpcap 生效点之后，才去使用正确的 mtu 去做切分。 |
| 12 swananan 2024-10-09 14:07:18 +08:00 我简单写了个测试代码，机器 a 往机器 b 发送数据，机器 a 代码，是建立 tcp 链接，然后应用层直接 tcp.send 65000 字节数据。（机器 a 支持 tso ） 机器 a 抓包：每个 tcp segment 大小是 2896 至少，远大于 mtu 值。 但是在机器 b 抓包：真实收到的 tcp segment 的大小还是 1500 ，符合 mtu 值。 所以，只是机器 a 的抓包，不能反应真正发出去的 tcp 报文内容，也就是抓包在 机器 a tso 生效之前 |
| 13 quanyajian 2024-10-09 14:27:58 +08:00 @sankooc 他的意思是服务端 172.16.21.10 发出包在达到你主机的时候被合并了。例如：就像这里的 LRO https://luckymrwang.github.io/2022/07/27/SmartNIC-%E2%80%94-TSO%E3%80%81GSO%E3%80%81LRO%E3%80%81GRO-%E6%8A%80%E6%9C%AF/ |
Select Language