问http响应上的tcp握手。哪个帧实际上是有效载荷？

EN

这看起来像是Wireshark重新组装了一个HTTP，该PDU是在多个TCP段之间分割的。PDU分为78、79和80段。Wireshark将PDU重新组装为框架80。

我也在Wireshark进行过类似的抓捕。

HTTP被分成三个TCP段:帧22743、22744和22746。Wireshark将前两个段显示为- is，但对于第三个段，HTTP被重新组装为帧22746。帧22746的以太网/IP/ TCP报头是原始帧的头，但TCP有效负载( HTTP )是来自所有三个段的重构PDU。

如果您查看片段22743的详细信息：

这表明PDU是作为框架22746的一部分重新组装的。框架22744的细节也显示了相同的内容：

现在来看一下框架22746的细节：

结果表明，22746是从22743、22744和原框架22746的内容中重新组装而成的。它还显示了每一段的长度和重建段的总长度。以太网/IP/ TCP报头是帧22746的，但TCP有效负载是完全重构的HTTP。

行78-80似乎是单个的、支离破碎的数据包的框架(注意点)。从大小判断，MTU有一个问题，只有几百个字节是不寻常的。

HTTP有效负载封装在TCP段中，而TCP段又封装在IP数据包中，而IP数据包又可以在多个帧中被碎片化。您只显示每个帧的最高层，所以第一个片段只显示为TCP，最后一个片段显示为HTTP。

哪个帧实际上是有效载荷？

都是。有效载荷被分配到碎片。

我们知道数据包77、78和79是同一个套接字的一部分，因为我们看到了它们的端口号。我们不能这样说76和80。我一直看到，当您不对客户端进行过滤时，只在两个I中进行过滤时就会发生这种情况。此外，77中的Ack只有19，这将是一个非常小的get请求，而500个字节将是一个非常大的304响应。如果是某种类型的重新组装(实际上并非如此)，就没有理由增加增量时间。这是不好的过滤。