关于 Wireshark 和 http/tcp 流答案

【问题标题】：About Wireshark and http/tcp stream关于 Wireshark 和 http/tcp 流
【发布时间】：2015-06-05 13:53:44
【问题描述】：

谁能告诉我为什么我在发送请求之前收到了 HTTP 200 响应？太奇怪了。

【问题讨论】：

【解决方案1】：

一种可能是您的捕获丢失了一个数据包 - 例如，由于某种原因，捕获跟踪的程序没有捕获该数据包。

Frame 747 是来自会话发起者（HTTP 客户端，即浏览器或...）的数据包，它是请求的一部分（可能是请求，因为它来自连接的发起者） t 适合单个链路层数据包。

Wireshark 将其报告为“重新组装的 PDU 的 TCP 段”，因为它没有找到包含请求的所有数据包，并且无法重新组装它（是的，这不是最好的措辞，因为 PDU 没有重新组装；我不确定用什么措辞会更好...）。

Wireshark 确实，在某些情况下，通过注意到 TCP 序列号空间中的“漏洞”来检测“丢失”的 TCP 段。您捕获的帧 746、747 和 750 的 TCP 序列号、段长度和“下一个序列号”值是多少？

【讨论】：

我抓了好几次，每次都得到相同的结果。太奇怪了。我发现 TCP 744[SYN WS=64], TCP 745[SYN,ACK WS: NOT SET], 为什么 TCP 746[ACK] 仍然使用 WS=64？
请根据我对 Den 回答的评论，在 Wireshark Bugzilla 上提交一个错误。
你能分享转储吗？数据不够。
@Den，我附上了错误的转储，bugs.wireshark.org/bugzilla/show_bug.cgi?id=11104
@Field.wei 我已经根据转储中的数据更新了我的答案

【解决方案2】：

实际上 GET 请求是在 #747 包中发送的。您可以从以下事实中了解它：

此请求没有正文，但有Content-Type 标头。我猜是因为这个头，Wireshark 认为它会是一个主体，并试图等到数据包#776。我检查了类似的情况，但没有 Content-Type 标头，Wireshark 在正确的位置显示请求。

RFC 说“请求中存在消息体是通过在请求的消息头中包含 Content-Length 或 Transfer-Encoding 头字段来表示的。”所以不应该有身体。但据我所知，Wireshark 甚至可以使用非标准或未良好实现的协议变体。所以我认为这不是一个错误。

【讨论】：

也许 GET 请求没有 Content-Length 标头，而 Wireshark 正在等待连接结束 (FIN) 以表明请求已完成。由于服务器显然不想要连接结束指示，这可能是一个 Wireshark 错误； Field.wei 应该在the Wireshark Bugzilla 提交错误并将捕获附加到错误中。
@GuyHarris GET 请求通常没有正文和 Content-Length 标头。我刚刚检查了 Chrome 的请求：没有 Content-Length 但 Wireshark 在响应之前正确显示它。也许来自问题的请求 has Content-Length !=0 但服务器忽略了它。
这就是为什么我想要提交错误并附加捕获 - 所以我们可以看到为什么 Wireshark 认为需要一些（重新）组装。 :-)
@GuyHarris 我报告了一个错误：bugs.wireshark.org/bugzilla/show_bug.cgi?id=11104
@GuyHarris 感谢 cmets。我已经更新了我的答案。