如果我有一个大的 HTTP 数据包，它已被拆分为多个 TCP 数据包，我如何将它们重新构建为单个 HTTP 数据包？基本上，我在数据包中的哪个位置查看 HTTP 数据包何时开始/结束？我似乎看不到 TCP 标头中表示 HTTP 数据包开始或结束的任何标志/字段。
编辑：跟进回复。如果 TCP 管理流，它如何知道流何时开始和结束？那是由插座打开和关闭决定的吗？某些协议在某种程度上必须能够知道 HTTP 流/数据包何时开始和结束。这就是我想知道的。
我现在的情况是我在 C# 中使用了一个数据包嗅探器，它读取 TCP 数据包，我希望能够重建 HTTP 请求/响应/等。像wireshark和其他各种嗅探器一样通过界面。或者，是否有任何 C# 库可以让您在更高级别利用 HTTP 流，而不必自己重建 HTTP 流/数据包？
谢谢。
【问题讨论】：
好的，我想出了如何做到这一点（狡猾，但它完成了工作）。
剥离以太网、IP 和 TCP 标头很简单，只剩下“原始”数据消息。查看消息内部，通过在数据包开头查找“HTTP/1.1 ...”很容易检测它是否是 HTTP 数据包的开头。这表明数据包是 HTTP 流/更大数据包/其他的开始。您也可以做一些简单的解析来读取“Content-Length”字段，它是整个 HTTP 数据包的总长度。
您还可以使用源/目标 IP 和端口号来形成链接的唯一 ID。所以收到header包后，注意这4件事（SRCIP、SRCPORT、DESTIP、DESTPORT）。下次您收到匹配此端口/IP 组合的数据包时，您可以检查它是否是 HTTP 数据包的下一部分。您可以使用序列号进行一些验证和可能的其他事情，但通常数据包是按顺序排列的，所以没关系。我认为为每个 HTTP 流打开了一个新端口，因此您不应该接收不属于该流的随机数据包，但这可能是一个容易出错的区域。
无论如何，一旦您收到此数据包，请再次剥离标头并获取原始消息。将其添加到消息的已知部分。如果到目前为止收到的总消息长度等于从“Content-Length”字段读取的长度，则数据包完成！
这种方法显然容易出现大量错误，但我并不追求一种非常健壮的方法。我想我会回答我自己的问题，以防其他人将来遇到同样的问题！祝你嗅探好运：D
【讨论】：
Content-Length 标头没有指定总数据包长度。它仅指定内容的大小，即正文的大小，它位于标题之后。标题和正文由\r\n\r\n分隔。
您不应使用 TCP 级别的任何信息来确定 HTTP 请求边界。 TCP提供可靠的字节流服务；您在 TCP 中看不到任何有助于解决此问题的字段或标志，因为它们不存在。
要确定 HTTP 请求中的边界在哪里，您应该遵循 RFC 2616。边界已明确定义，您可以通过解析收到的数据来确定它们。
【讨论】：
在每个 TCP 数据包中，有效载荷数据的开始紧跟在 TCP 标头之后，有效载荷数据的结尾是 IP 数据包的结尾。
很容易找到 TCP 标头的结尾 - Data Offset 是标头中的一个 4 位字段，包含以 32 位字表示的标头长度（因此将其乘以 4 得到 8 中的长度-bit 字节）。
使用来自Sequence 字段的 TCP 序列号以正确的顺序将有效负载串在一起。请注意，在重新传输的情况下，可能会有重复。
【讨论】：
TCP 是 stream 协议，而不是数据包协议。应用层（即您）获取数据流，而不是一堆数据包。您只需继续从流中读取字节，您将获得整个 http 有效负载，而 TCP 在下面进行错误检查、重新发送等。
【讨论】：
您可以使用名为 Xplico 的开源项目的代码： http://www.xplico.org
【讨论】：
【讨论】：
Content-Encoding 标头解压缩压缩数据，b) 转换为基于 Content-Type 标头中的 charset 的通用文本编码和 c)当Transfer-Encoding标头设置为chunked时处理分块编码？