☰

HTTP 作为一种协议是否包含任何保证信息的机制？

tag-icon • tag-icon networking http tcp
HTTP 作为一种协议是否包含任何保证信息的机制？

我在 networkengineering.stackexchange 上问了这个问题，但没有意识到 TCP 之上的任何协议都是题外话（即只有 OSI 第 4 层及以下的协议才是主题）。

问题是这样的：

由于 HTTP 是在 TCP 之上实现的，并且 TCP 是无损的，那么 HTTP 是否包含任何类型的用于数据包组装的信息？

我想象一旦 HTTP 请求完成，您就可以假设 HTTP 信息是完整的（因为用于传输 HTTP 的整个 TCP 数据包序列保证是有序且完整的）。

这个假设正确吗？

快速谷歌搜索显示，OSI 第 4 层专门处理端到端连接和可靠性，这使我了解到 HTTP 数据包在重新组装时不需要任何检查完整性的方法。即，在网络传输结束时，如果 TCP 会话无错误完成，则 HTTP 数据包将被完整且正确地组装。

它是否正确？

答案1

是的，HTTP/1.x 不包含任何数据包重组/重新传送机制。它期望传输层（通常是 TCP 或 QUIC）提供它，如RFC 7230，第 6 节：

6.连接管理

HTTP 消息传递独立于底层传输层或会话层连接协议。HTTP 仅假定传输可靠，请求按序传递，响应也按序传递。

也就是说，HTTP/1.x做包括用于识别何时响应的可选机制完全的。这是必要的，因为 HTTP/1.x 支持连接重用，并且相同的底层 TCP 连接可用于多个请求/响应对。（当然，TCP 没有单独消息的概念。）

使用“Connection: close”（HTTP/1.0 中的默认设置）的客户端可以简单地假设干净关闭的 TCP 连接表示响应结束。但是，使用“Connection: keep-alive”（HTTP/1.1 中的默认设置）的客户端希望响应具有以下任一特征：

  1. 如果响应长度确定且已知，则为“Content-Length:”标头，或者
  2. 如果响应的长度不确定并且使用“Transfer-Encoding: chunked”，则为零长度块。

TCP 上的 HTTP/2，甚至 QUIC 上的 HTTP 也是如此。

相关内容