V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member Sign In
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 566 days ago, the information mentioned may be changed or developed.
事情是这样, 我发现 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. 是通过应用层?
Supplement 1 · Oct 9, 2024
 |
1
turi Oct 9, 2024
tcp tso
|
 |
2
quanyajian Oct 9, 2024
看你的第二个握手包 SYN-ACK ，里面应该也有一个 MSS 。
|
 |
3
sankooc OP @quanyajian 第二个 mss 是 1460 也跟 tcp 的 payload 相差很大
|
|
4
sankooc OP @turi 那能理解为 NIC 会通过网络情况会自动分包? 那 wireshark 分析的时候是如何判断出这些包是 segment 呢? 主要我最近做一个类似 wireshark 的工具 现在卡在合并应用层数据
|
|
5
quanyajian Oct 9, 2024
把 pcap 文件贴出来看看
|
|
6
quanyajian Oct 9, 2024
@sankooc 你应该是要做 tcp 重组，我这边用的 gopacket 实现的。
|
 |
7
swananan Oct 9, 2024
抓包是在 网卡 tso 生效之前，所以还是大于 mtu 的报文，然后也符合 tcp 的格式，所以 wireshark 能够正常解析。
你要是在对端抓包，应该就是 网卡 tso 切分后的报文。 |
|
8
sankooc OP @quanyajian pcap 附上了 这个包我研究一下
|
|
9
sankooc OP @swananan 你是说通过 pmtud? 但是 segment 的大小应该是取 mtu 和 mss 的最小值 而且大于 mss 的 tcp 包并非都是 segment
|
 |
10
ccsexyz Oct 9, 2024
搜索一下关键词 TCP GRO/GSO
|
|
11
swananan Oct 9, 2024
@sankooc 我不是这个意思，和 mtu 发现没关系。我意思是用了 tso 或者 gso 这种手段，那么抓包看到的 mtu 就不准了。因为这些手段都是在 libpcap 生效点之后，才去使用正确的 mtu 去做切分。
|
|
12
swananan Oct 9, 2024
我简单写了个测试代码，机器 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 Oct 9, 2024
@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