HTTP/1.1 是不是允许通过半关闭连接来分隔请求结束？

Posted 2023-03-23

【中文标题】HTTP/1.1 是不是允许通过半关闭连接来分隔请求结束？

【英文标题】：Does HTTP/1.1 allow delimiting end of request by half-closing the connection?HTTP/1.1 是否允许通过半关闭连接来分隔请求结束？

【发布时间】：2012-12-13 17:04:01

【问题描述】：

RFC2616 part 4.4 指定在 HTTP/1.1 中如何确定消息的结尾。该部分中的第 5 项指定服务器可以关闭连接以指示响应完成。

它还继续说，像这样划分请求是不可能的。但是，TCP 允许客户端关闭其端并继续接收响应。我什至测试过它；它有效。

问题：

为什么 1999 年的标准说这实际上是不可能的？那时 TCP 已经很成熟了，并且在很长一段时间内都支持半关闭（可能从 1974 年就一直支持？）。

客户端半关闭连接以表示请求结束是否违反协议？

请忽略这是否是个好主意：我知道您有时无法完全判断连接是故意关闭还是刚刚断开，以及保持连接打开以供重用如何更有意义以后再说吧。

【问题讨论】：

听起来您在这里有点偏离地图，但我真的很想知道如何您在关闭连接后测试收到一条消息？我怀疑连接没有关闭——只是你发送了一个 FIN 数据包。

也许是因为规范被编写为独立于连接协议，因此他们不想过度依赖其他协议可能没有的功能

@symcbean 没错，它没有关闭。它是半关闭的，我认为这是另一种说法，我发送了一个 FIN 数据包但另一端保持打开状态，即就像你说的那样。

TCP 的行为不是由应用程序定义的，因此从 HTTP RFC 中得出关于 TCP 应该如何行为的结论不是一个富有成果的追求吗？考虑到分组交换网络的性质，应用程序在发出 FIN 后仍然可以接收和处理发送的数据，我并不感到惊讶。但是通常是客户端关闭连接，大多数HTTP客户端不会关闭带有FIN的连接，它们使用RST，并且在服务器发送FIN包然后发送后续数据包的情况下应该是不可能的（没有 MITM 位翻转）。

@symcbean 这完全无关紧要。当 RFC 793 中定义 TCP 时，没有理由您应该“感到惊讶”，而这又不是分组交换网络本身的必然结果。您关于“大多数 HTTP 客户端”的断言是站不住脚的。您的最后一句话也与此处所述的任何内容无关。简而言之，我也无法理解您的观点。

【参考方案1】：

这并不是说半关闭是不可能的。它只是说'关闭连接不能用于指示请求正文的结束'，这是真的。它根本不考虑以一种或另一种方式半关闭的可能性。由于 RFC 中没有提到它，我会说使用它会违反协议，并且您不应该期望服务器做出相应的反应：例如，服务器有权忘记请求并且收到 FIN 后关闭连接。

【讨论】：

此外，nginx 就是这样工作的。 mailman.nginx.org/pipermail/nginx/2008-September/007388.html