事情是这样, 我发现 tcp 实际的 payload 长度和握手时协商的 MSS 长度多出很多.
按理来说根据不同的路由环境 segment 的长度比 mss 小可以理解,但是比 mss 大这就有点诡异了
下图时我的问题发生现场, 图 1 确认 mss 长度(图片有点模糊 显示的是 1357), 图 2 中 192.168.8.104 发送的 tcp segment 却比 mss 大很多
<center>图 1</center>图 2 中的 segment 长度正好是 mss 的两倍 但在别的 frame 中也能找到非整数倍的 segment
我想知道的是 wireshark 是如何确认一个 tcp frame 是否为 segment 一开始以为是通过 mss 长度但发现这并不可靠, 也有很多特别小的 segment. 是通过应用层?
1
turi 75 天前
tcp tso
|
2
quanyajian 75 天前
看你的第二个握手包 SYN-ACK ,里面应该也有一个 MSS 。
|
3
sankooc OP @quanyajian 第二个 mss 是 1460 也跟 tcp 的 payload 相差很大
|
4
sankooc OP @turi 那能理解为 NIC 会通过网络情况会自动分包? 那 wireshark 分析的时候是如何判断出这些包是 segment 呢? 主要我最近做一个类似 wireshark 的工具 现在卡在合并应用层数据
|
5
quanyajian 75 天前
把 pcap 文件贴出来看看
|
6
quanyajian 75 天前
@sankooc 你应该是要做 tcp 重组,我这边用的 gopacket 实现的。
|
7
swananan 75 天前
抓包是在 网卡 tso 生效之前,所以还是大于 mtu 的报文,然后也符合 tcp 的格式,所以 wireshark 能够正常解析。
你要是在对端抓包,应该就是 网卡 tso 切分后的报文。 |
8
sankooc OP @quanyajian pcap 附上了 这个包我研究一下
|
9
sankooc OP @swananan 你是说通过 pmtud? 但是 segment 的大小应该是取 mtu 和 mss 的最小值 而且大于 mss 的 tcp 包并非都是 segment
|
10
ccsexyz 75 天前
搜索一下关键词 TCP GRO/GSO
|
11
swananan 75 天前
@sankooc 我不是这个意思,和 mtu 发现没关系。我意思是用了 tso 或者 gso 这种手段,那么抓包看到的 mtu 就不准了。因为这些手段都是在 libpcap 生效点之后,才去使用正确的 mtu 去做切分。
|
12
swananan 75 天前
我简单写了个测试代码,机器 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 75 天前
@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/
|