浏览器如何处理 HTTP keepalive 竞争条件？答案

【问题标题】：How do browsers handle HTTP keepalive race condition?浏览器如何处理 HTTP keepalive 竞争条件？
【发布时间】：2017-07-26 15:45:00
【问题描述】：

HTTP keepalive 机制中存在已知的竞争条件：

据我了解，我需要我的 HTTP 客户端的超时时间短于我的 HTTP 服务器，或者在获取 TCP-FIN 或 TCP-RST 时重试。

我的问题是，今天的网络浏览器 use the HTTP keepalive feature 如何处理这种竞争条件。他们会重试吗？

我很乐意参考，谷歌搜索没有找到任何东西。

【问题讨论】：

【解决方案1】：

根据RFC，在这些情况下，服务器应以 408 错误代码响应，向客户端发出信号，表明连接已在其一侧关闭。正如 RFC 所述：

如果客户端在传输过程中有未完成的请求，客户端可以在新连接上重复该请求。

这意味着由客户端（也就是每个浏览器）决定如何处理 408 响应。有两种选择：

例如，Chrome 过去似乎一直遵循第二种方法，直到人们开始将此视为“错误”行为并切换到第一种。您可以找到与 Chromium 错误 here 相关的错误线程以及相关的代码更改 here。

注意：正如您在链接线程中的最终电子邮件中看到的那样，Chrome 仅在某些请求在此连接中成功时才会执行这些重试。因此，如果您尝试使用单个请求来重现它并返回 408 响应，您会注意到 Chrome 在这种情况下可能不会重试。

【讨论】：

感谢您抽出宝贵时间对此进行研究。
408 响应代码用于请求超时 - 客户端已开始发送请求但发送速度不够快的情况。在 Keepalive 竞赛中，当连接空闲一段时间并且服务器没有可以看到的正在进行的请求时，服务器会关闭连接，因此它无法向客户端发送 408 响应。
@avmohan 我不认为这是正确的。即使客户端打开了连接并且根本没有发送任何数据包，服务器也会以 408 响应。例如，请参阅：developer.mozilla.org/en-US/docs/Web/HTTP/Status/408
感谢您的参考，Dimos。我不知道在没有请求的情况下会有回应。很高兴知道。我已经看到 Apache httpd 作为反向代理和 tomcat 之间的这些竞争条件。 Tomcat 关闭持久连接（不发送 408），同时 httpd 转发来自客户端的请求，导致 502 错误给客户端。我们可以解决这些问题的唯一方法是保持 httpd 上的空闲超时低于 tomcat。