为什么单个（？）TCP 数据包在这里被拆分为多个 PDU 单元？

Question

图片相关：

为什么这些段被标记为单独的数据包（所有 Ack，Seq=509）？为什么数据包被拆分？

Answer 1

我看不到图片，但是较低级别的协议（例如以太网）可以根据其 MTU（最大传输单元）的大小将较高级别的协议（例如 TCP 数据包）分解为片段。

Answer 2

我认为您指的是 56-78 范围内的可见帧。
让我们按这个顺序处理事情，

1. 关于：“ TCP segment of a reassembled PDU”
   这意味着wireshark（ethereal？）将TCP Segments重新组装在一起以供您查看。
   所以，你可以忽略这个字符串，这意味着没有什么坏处。
   ^{我在下面的第 4 点中详细阐述了这些框架的含义。}
2. 关于：具有相同“ seq”编号的不同帧。
   帧 58、60、62、64 等显示相同的序列号。
   但是，请注意，这些不是“标记为单独数据包”的单个数据包 - 没有拆分。
   这些数据包仅ACK设置了“ ”标志，您将看到 ACK 编号正在递增。
   这些是当不同的 TCP 段到达时从您的计算机发送到 HTTP 服务器的 ACK。
3. ' ACK' 序列从1in 帧开始，到 FIN 帧52结束。 在此期间，从浏览器到 HTTP 服务器的所有帧都会重复发送的最后一个序列号（即）——这是正常的 TCP 协议行为。 浏览器在第一个 HTTP 请求（帧）之后不再发送任何进一步的数据。 HTTP 服务器在 帧 中确认了这一点。964678
609
52
54
4. 我期望帧54是（wireshark）重新组装的服务器响应，它是由标记为“重新组装的 PDU 的 TCP 段”的帧形成的。
   因此，以这种方式标记的所有后续帧都是从 HTTP 服务器到客户端的
   （由于您擦洗了“源”和“目标”列，因此在图片中看不到该详细信息）。

如果您重新检查原始捕获文件，您应该会发现具有 TCP 源端口 80（对于 HTTP）的帧 54 到 67 将总计来自 HTTP 服务器的 9646 字节响应数据。

您在这里看到的是来自 HTTP 服务器的 9KB 回复，作为几个 MTU 限制的 TCP 段到达您的浏览器，每个段都被操作系统的 TCP 堆栈确认。

这是高级别的通信序列。

1. 您的浏览器通过 3 路 TCP 握手开始连接到 HTTP 服务器。
2. 它在此连接上向服务器发送了一个 HTTP 请求
3. 服务器用 9 KB 的响应对此进行回复，该响应分布在多个 TCP/IP 数据包中（TCP 段）
4. 当从服务器接收到每个 TCP 数据包时，浏览器计算机上的 TCP/IP 堆栈会对其进行确认
5. 最后，它关闭了以数据包开头的连接FIN。我预计在第 78 帧（或单个数据包）之后
   还有更多FIN数据包。ACKRST

您可以在Wireshark Wiki上阅读有关 Wireshark TCP 重组处理的更多信息。