从pcap重构HTTP浏览

我目前正在尝试仅使用pcap自动重建HTTP浏览（基本上这意味着将HTTP回复与下一个HTTP请求相匹配）。大多数情况下，它工作正常，但有时在多个HTTP回复的数据中存在某个url u

例如，如果u1和u2的回复数据中包含u，并且如果对u的请求发生在对u2的请求之后，我如何确定对u的请求是由u1还是由u2引起的？注意，在u1和u2之间没有向u发出请求

在任何网络层中是否有一些字段可以用于匹配

---

谢谢

HTTP在面向连接的TCP之上运行。您可以访问用于HTTP请求的连接的IP头（客户端IP/端口->服务器IP/端口）

HTTP是一种命令/响应协议，每个请求有一个响应

因此，只需在同一TCP连接（服务器IP/端口->客户端IP/端口）上的HTTP请求之后立即查找HTTP响应

---

HTTP是无状态的，请求之间的连接可以关闭，而不会影响整个浏览模型（关闭连接是HTTP 0.9中的必需行为，是HTTP 1.0中的默认行为，而不是HTTP 1.1+中的默认行为，因此HTTP响应可以触发新连接上的后续请求，所以你需要准备好处理这件事。HTTP请求中的

连接

头将告诉您客户端是否要求连接保持打开状态。HTTP响应中的

连接

头将告诉您发送响应后服务器是否实际关闭连接。但是，即使服务器保持连接打开，也不能保证客户端会在以后对同一服务器的请求中重新使用相同的连接（尽管很可能会，除非请求之间超时）。

感谢这些解释。实际上，我尝试将响应与请求相匹配，而不是相反（我使用tcptrace分割不同的TCP会话）。我的理解是，对于与前一个响应相同的服务器的请求，客户端可以使用或不使用相同的连接，并且总是为不同的服务器启动新连接。这意味着没有一种“网络”方式来关联属于不同TCP连接的不同HTTP数据包。如果您拆分了TCP连接，则很容易将响应与请求进行匹配，因为它们始终位于彼此相同的连接上。从响应开始，在同一个连接上查找紧跟在它前面的请求。在多个连接上尝试匹配相关请求比较困难。不，没有明确的网络唯一标识符将它们连接在一起。您可以在给定的时间范围内比较数据包的客户端IP（端口通常是随机的）和服务器IP/端口。但是，您可能更需要分析实际的HTTP请求/响应数据，查找HTTP重定向到新URL的想法，检查请求是否具有与以前响应的URL匹配的

Referer

头，跟踪HTTP cookie流，等等。是的，我已经这样做了。当同一个网站在同一时间被浏览两次时，问题就出现了，这就是我在第一篇文章中试图解释的。如果url u位于回复url 1和回复url 2的数据中。如果对url u的请求发生在两个回复之后，我无法确定这是由对url 1的回复还是由回复tp url2引起的。根据你所说的，似乎没有一个真正的解决方案，不使用启发式，来解决这个问题。这真的重要吗？如果用户浏览到

url1

，得到一个包含

u

的响应，然后用户手动浏览到

u

（书签、键入地址栏等），因此它不是一个自动请求，

u

与

url1

位于同一服务器上，该怎么办，并且连接超时尚未过去，因此浏览器将重用与服务器的现有连接。这两节课并没有真正的联系，但你怎么知道其中的一种或另一种呢？