事情是这样, 我发现 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 条附言 · 27 天前
14 条回复
 |
1
turi 27 天前
tcp tso
|
 |
2
quanyajian 27 天前
看你的第二个握手包 SYN-ACK ，里面应该也有一个 MSS 。
|
 |
3
sankooc OP @quanyajian 第二个 mss 是 1460 也跟 tcp 的 payload 相差很大
|
|
4
sankooc OP @turi 那能理解为 NIC 会通过网络情况会自动分包? 那 wireshark 分析的时候是如何判断出这些包是 segment 呢? 主要我最近做一个类似 wireshark 的工具 现在卡在合并应用层数据
|
|
5
quanyajian 27 天前
把 pcap 文件贴出来看看
|
|
6
quanyajian 27 天前
@sankooc 你应该是要做 tcp 重组，我这边用的 gopacket 实现的。
|
 |
7
swananan 27 天前
抓包是在 网卡 tso 生效之前，所以还是大于 mtu 的报文，然后也符合 tcp 的格式，所以 wireshark 能够正常解析。
你要是在对端抓包，应该就是 网卡 tso 切分后的报文。 |
|
8
sankooc OP @quanyajian pcap 附上了 这个包我研究一下
|
|
9
sankooc OP @swananan 你是说通过 pmtud? 但是 segment 的大小应该是取 mtu 和 mss 的最小值 而且大于 mss 的 tcp 包并非都是 segment
|
 |
10
ccsexyz 27 天前
搜索一下关键词 TCP GRO/GSO
|
|
11
swananan 27 天前
@sankooc 我不是这个意思，和 mtu 发现没关系。我意思是用了 tso 或者 gso 这种手段，那么抓包看到的 mtu 就不准了。因为这些手段都是在 libpcap 生效点之后，才去使用正确的 mtu 去做切分。
|
|
12
swananan 27 天前
我简单写了个测试代码，机器 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 27 天前
@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