有没有网络大佬 请教个判断 TCP Segment 的问题

[sankooc]

事情是这样, 我发现 tcp 实际的 payload 长度和握手时协商的 MSS 长度多出很多.

按理来说根据不同的路由环境 segment 的长度比 mss 小可以理解,但是比 mss 大这就有点诡异了

下图时我的问题发生现场, 图 1 确认 mss 长度(图片有点模糊 显示的是 1357), 图 2 中 192.168.8.104 发送的 tcp segment 却比 mss 大很多

图 2 中的 segment 长度正好是 mss 的两倍 但在别的 frame 中也能找到非整数倍的 segment

<center>图 1</center>

<center>图 2</center>

我想知道的是 wireshark 是如何确认一个 tcp frame 是否为 segment 一开始以为是通过 mss 长度但发现这并不可靠, 也有很多特别小的 segment. 是通过应用层?

pcap

其实搞这个主要是我摸鱼做了个小玩具 pcapviewer

欢迎大家试用, 但现在功能不全勿喷 哈 也有在线版 online

[turi]

tcp tso

[quanyajian]

看你的第二个握手包 SYN-ACK ，里面应该也有一个 MSS 。

[sankooc]

@quanyajian 第二个 mss 是 1460 也跟 tcp 的 payload 相差很大

[sankooc]

@turi 那能理解为 NIC 会通过网络情况会自动分包? 那 wireshark 分析的时候是如何判断出这些包是 segment 呢? 主要我最近做一个类似 wireshark 的工具 现在卡在合并应用层数据

[quanyajian]

把 pcap 文件贴出来看看

[quanyajian]

@sankooc 你应该是要做 tcp 重组，我这边用的 gopacket 实现的。

[swananan]

抓包是在 网卡 tso 生效之前，所以还是大于 mtu 的报文，然后也符合 tcp 的格式，所以 wireshark 能够正常解析。
你要是在对端抓包，应该就是 网卡 tso 切分后的报文。

[sankooc]

@quanyajian pcap 附上了 这个包我研究一下

[sankooc]

@swananan 你是说通过 pmtud? 但是 segment 的大小应该是取 mtu 和 mss 的最小值 而且大于 mss 的 tcp 包并非都是 segment

[ccsexyz]

搜索一下关键词 TCP GRO/GSO

[swananan]

@sankooc 我不是这个意思，和 mtu 发现没关系。我意思是用了 tso 或者 gso 这种手段，那么抓包看到的 mtu 就不准了。因为这些手段都是在 libpcap 生效点之后，才去使用正确的 mtu 去做切分。

[swananan]

我简单写了个测试代码，机器 a 往机器 b 发送数据，机器 a 代码，是建立 tcp 链接，然后应用层直接 tcp.send 65000 字节数据。（机器 a 支持 tso ）
机器 a 抓包：每个 tcp segment 大小是 2896 至少，远大于 mtu 值。
但是在机器 b 抓包：真实收到的 tcp segment 的大小还是 1500 ，符合 mtu 值。
所以，只是机器 a 的抓包，不能反应真正发出去的 tcp 报文内容，也就是抓包在 机器 a tso 生效之前

[quanyajian]

@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/

[sankooc]

@swananan ok 这会理解了