HTTP数据包重建 [英] HTTP packet reconstruction

问题描述

如果我有一个大的HTTP数据包已被拆分成多个TCP数据包，我怎样才能将它们重新组合成一个HTTP数据包？基本上，在数据包的哪个位置，我想知道HTTP数据包何时开始/结束？我似乎无法在TCP标头中看到任何表示HTTP数据包开始或结束的标志/字段。

If I have a large HTTP packet which has been split up into a number of TCP packets, how can I reconstruct them back into a single HTTP packet? Basically, where in the packet do I look to tell when a HTTP packet is starting/ending? I can't seem to see any flags/fields in the TCP header that denote the start or end of the HTTP packet.

编辑：跟进回复。如果TCP管理流，它如何知道流的开始和结束时间？这是由插座开合决定的吗？某些协议在某种程度上必须能够知道HTTP流/数据包何时开始和结束。这就是我想知道的。

In follow up to the responses. If TCP manages the stream, how does it know when the stream starts and ends? Is that determined by the socket opening and closing? Some protocol, at some level, must be able to know when the HTTP stream/packet has started and ended. That is what I would like to know.

我所处的情况是我在C＃中使用数据包嗅探器读取TCP数据包，我想成为能够重建HTTP请求/响应/等。像wireshark和其他各种嗅探器一样经历界面。或者，是否有任何C＃库可以让您在更高级别使用HTTP流，节省了我自己重建HTTP流/数据包的时间？

The situation I am in is I am using a packet sniffer in C# which reads in TCP packets, and I would like to be able to reconstruct the HTTP requests/responses/etc. going through the interface like how wireshark and various other sniffers manage to. Alternatively are there any C# libraries that let you tap into the HTTP streams at the higher level, saving me having to reconstruct the HTTP stream/packets myself?

谢谢。

推荐答案

好吧我确定了如何做到这一点（狡猾但它完成了工作）。

OK I worked out how to do this (dodgy but it gets the job done).

删除以太网，IP和TCP标头很简单，只留下原始数据消息。查看消息内部，通过在数据包开头查找HTTP / 1.1 ...，可以轻松检测到它是否是HTTP数据包的开始。这表明数据包是HTTP流/更大数据包/无论什么的开始。您还可以执行一些简单的解析来读取Content-Length字段，该字段是整个HTTP数据包的总长度。

It is simple to strip away the Ethernet, IP, and TCP headers leaving you with the 'raw' data message. Looking inside the message, it is easy to detect whether it is the start of a HTTP packet by looking for the "HTTP/1.1 ..." at the start of the packet. This indicates the packet is the start of a HTTP stream/larger packet/whatever. You can also do some simple parsing to read the "Content-Length" field which is the total length of the entire HTTP packet.

您还可以使用Source / Destination知识产权与端口号，以形成链接的唯一ID。因此，在收到标头包后，请注意这4件事（SRCIP，SRCPORT，DESTIP，DESTPORT）。下次收到与此端口/ ip组合匹配的数据包时，您可以检查它是否是HTTP数据包的下一部分。您可以使用序列号进行一些验证，也可能使用其他东西，但通常数据包都是有序的，所以没关系。我认为为每个HTTP流打开了一个新端口，因此您不应该接收不属于流的随机数据包，但这可能是一个容易出错的区域。

You can also use the Source/Destination IP & Port numbers to form a unique ID for the link. So after receiving the header packet, take note of these 4 things (SRCIP, SRCPORT, DESTIP, DESTPORT). Next time you receive a packet matching this port/ip combo, you can check whether it's the next part of the HTTP packet. You can use the sequence numbers to do some validation and probably other stuff, but generally the packets are in order so it's OK. I think a new port is opened for each HTTP stream so you shouldn't receive random packets that aren't part of the stream, but this could be an area prone for error.

无论如何，一旦收到此数据包，再次剥离标题并获取原始消息。将其添加到消息的已知部分。如果到目前为止收到的总消息长度等于从Content-Length字段读取的长度，则数据包完成！

Anyway, once you received this packet, once again strip away the headers and get the raw message. Add it onto the already known part of the message. If the length of the total message received so far is equal to the length read from "Content-Length" field, the packet is complete!

这种方法显然很容易大量的错误，但我并没有采取非常强大的方式。我想我会回答我自己的问题，以防其他人在将来遇到同样的问题！祝你嗅闻好运：D

This method is obviously prone to a huge amount of errors, but I am not after an extremely robust way of doing it. I thought I would answer my own question in case someone else comes across this same issue in the future! Good luck with your sniffing :D

这篇关于HTTP数据包重建的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！