HTTP数据包重建

mik*_*ike 8 tcp http sniffer packet

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

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

我所处的情况是我在C#中使用数据包嗅探器读取TCP数据包,我希望能够重建HTTP请求/响应/等.像wireshark和其他各种嗅探器一样通过界面.或者,是否有任何C#库可以让您在更高级别进入HTTP流,从而节省了我自己重建HTTP流/数据包的麻烦?

谢谢.

mik*_*ike 11

好吧,我找到了如何做到这一点(狡猾,但它完成了工作).

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

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

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

这种方法显然容易出现大量错误,但我并不是一种非常强大的方法.我想我会回答我自己的问题,以防其他人在将来遇到同样的问题!祝你嗅闻好运:D

  • 如果未指定Content-Length字段,则还有其他方法可以计算长度.例如http://www.httpwatch.com/httpgallery/chunked/ (2认同)
  • 可能有点晚,但`Content-Length`标头不指定总包长度.它只是指定内容的大小,因此是标题之后的主体.标题和正文由`\ r \n\r \n`分隔. (2认同)

jan*_*anm 7

您不应该使用TCP级别的任何信息来确定HTTP请求边界.TCP提供可靠的字节流服务; 您无法在TCP中看到任何有助于此的字段或标志,因为它们不存在.

要确定HTTP请求中边界的位置,您应该遵循RFC 2616.边界是明确定义的,您可以通过解析收到的数据来确定它们.


caf*_*caf 5

在每个 TCP 数据包中,有效载荷数据的开头紧跟在 TCP 头之后,有效载荷数据的结尾是 IP 数据包的结尾。

TCP 标头的结尾很容易找到——它Data Offset是标头中的一个 4 位字段,包含以 32 位字表示的标头长度(因此将其乘以 4 以获得 8 位字节的长度)。

使用Sequence字段中的 TCP 序列号以正确的顺序将有效负载串在一起。请注意,在重传的情况下,可能存在重复项。