Wireshark 跟踪 - SLE 和 SRE 缺少序列号的 POST 数据

网络工程 以太网 无线的 通讯协议 线鲨
2021-07-07 17:17:22

在此处输入图片说明

-Segment 237,客户端(10.xxx)向服务器(128xxx)发送POST请求,payload为(TCP Len)4096。

-Segment 238,客户端继续传输,payload 1460 (seq 4097-5557)

-239,服务器 128.xxx 以 Ack=1461 确认收到了段 238(对吗??)

此时似乎缺少 237 的 Ack,因为服务器还没有收到它(前 1-4096 字节的数据)。

- 但是,在 243 处,服务器告诉客户端,服务器实际上丢失了序列号为 1-1460(这些丢失的数据来自段 237,而不是 238??)和序列号 1461-4097(部分来自237) 已收到。

-244,服务器更新 SACK,说它缺少序列号为 1-1460 的数据,并且已收到序列号 1461-5557(假设 4097-5557 之间的序列号来自服务器之前确认的段 238 239)。

我是否正确地打断了这个?如果我错了,请纠正我,因为稍后在跟踪中我没有看到丢失的 seq num 1-1460 的任何重传:https ://www.cloudshark.org/captures/1a890ba09b92

任何帮助将不胜感激。谢谢。

1个回答

我认为您误解了最初的 ACK。第一个段长 4150 字节,这远远超过大多数标准段的容量,通常表明主机正在执行 TCP 大段卸载,这允许应用层(包括 PCap)认为您正在发送大段,但 NIC 实际上将它们拆分为与 MSS/MTU 限制兼容的较小段。

因此,这里不是发送数据大小为 4096 字节的一个段,而是发送三个:两个 1460 字节和一个 1176 字节(或类似的内容)。因此,此捕获中的第 238 帧实际上是实际发送的第 4 段

这一系列的 ACK 看起来很奇怪,就好像你在这个网络中有乱序的数据包传递。如果您首先收到第 243 和 244 段(您得到了字节 1461 到 5557 的段,因此您 SACK)然后第一个数据包到达并被确认(数据包 239),然后在数据包 245,这似乎更合乎逻辑一切都被赶上了。

老实说,我不明白你怎么能得到这个特定的片段序列,除非:

  1. 从客户端到服务器的数据包有多个不同延迟的路径,

  1. 有一些东西在摆弄初始 ACK,即使服务器实际上没有收到第一个片段,它也会发送它。

客户端和服务器之间是否有 WAN 优化设备,例如 Riverbed?它们具有尝试尽可能快地对某些段进行 ACK 的机制,以加速会话的吞吐量上升。

我在这里可能完全错了;这真是一个不寻常的序列!