chrome 请求卡在等待中

AKn*_*nox 9 ssl nginx chrome

问题描述

我们有一个服务于静态资产的网络服务器。我们遇到了一个问题,在您浏览一些 http 请求后,它会卡在“待处理”状态。在 chrome 检查器中,响应标头确实会返回,但请求不会超时,并且看起来像是在下载。在时间线视图中,“等待 (ttfb)”是最后填写的项目(例如 400 毫秒),然后有一个注释“注意:请求尚未完成!”

这个问题似乎仅限于 chrome,并且当网站运行 https 时。我们无法在 safari、ff、ie 上重现,如果 https 关闭,我们也无法重现。

再现。采取的步骤

  1. 打开 chrome 隐身
  2. 打开检查器工具 > 网络选项卡
  3. 导航到站点
  4. 通常第一页和它的所有请求都完成了
  5. 浏览到另一个页面
  6. 意外行为:页面的某些部分无法加载;xhr 请求 .html 文件,通常是 jpg 图像。在 chrome 的 net 选项卡中检查时,他们说“待定”

奇怪的注释:

  1. 按照上述步骤操作后,如果您在新选项卡中打开“待处理”请求,则该选项卡会“旋转”
  2. 如果您关闭第一个选项卡,带有“待处理”url 的第二个选项卡会解析,这会导致我们调查保持活动和超时,但无济于事。
  3. 这个完整的问题有时也会出现在第一个请求中(文档)

环境注意事项:

  • 前端是 angularjs,通过 chrome 访问其他浏览器似乎没有这个问题
  • 服务器运行 https,通配符证书( *.domain.com )
  • nginx 版本 1.9.3

    # some variables we've tweaked
    worker_processes 4;
    worker_connections 4000;
    keepalive_timeout 15;
    client_body_timeout 12;
    gzip on
    
    Run Code Online (Sandbox Code Playgroud)
  • nginx 日志不会抱怨任何事情

  • 当服务器上有负载时,cpu / ram 永远不会接近 maxxing
  • 响应头包括;etag、gzip、内容类型、日期、最后修改时间、服务器、状态(200)、严格传输安全:最大年龄=604800 ...
  • 更改 chrome 的“禁用缓存”复选框似乎没有影响
  • 我们在不同计算机上的 man chrome 浏览器上经历过这种情况。我最大运行 44.0 64 位

基于这些问题,该错误感觉像是某种类型的服务器配置问题,我们认为它与证书无关,但它仅影响 chrome 的事实确实很奇怪。

vla*_*bph 7

有关此问题或类似问题的大量信息,但没有一个解决方案对我有用。所以在挖掘之后 - 这是添加到服务器的响应标头['Connection'] ='close'

  • 定义“彻底”?一般来说,这种说法并不正确。正确的评论是 - 这取决于使用您的网络服务器提供的服务的模式。在我的例子中(再次,在我的例子中)网页加载时间和服务网络请求现在工作得更快(>10x),而且浏览器没有任何待处理的请求排队,否则从客户的角度来看,这被认为是无法提供服务(称之为解决方法)。因此,在某些情况下它可能会导致性能下降,在某些情况下它解决了ajax查询停滞的问题并提高了性能。 (2认同)
  • 我推测问题仍然出在服务器端。就我而言,chrome 和 firefox 的行为方式相同,直到我将“连接关闭”添加到服务器响应标头。 (2认同)

use*_*461 4

考虑wireshark使用 Chrome 开发人员工具来分析网络流量。

在 Chrome 中打开网络调试器并尝试重现卡住的请求。它将向您显示准确的时间表:请求标头完全发送后,请求内容已发送,等待回复,响应标头完全接收,收到内容的第一个字节,内容的最后一个字节(如果完成)。

确定问题处于哪个阶段很重要?

  • 如果一开始,Web 服务器从未收到请求,则可能一开始就无法建立连接。

  • 如果它卡在等待内容结束,这意味着Web服务器完全接收并处理了请求,您应该能够在Web服务器日志中看到该请求,带有状态代码可能是错误?

我遇到过许多现实世界中的事情,这些事情会破坏响应或减慢传输速度。

  • 积极的流量整形。必须在伦敦的一间办公室与亚洲服务器进行通信。第一个 MB 的响应正常,然后传输速度上限为 20 KB/s。它没有坏,只是速度慢得令人难以置信。

  • 代理问题,尤其是 MITM 代理。它们可以无特殊原因地断开或保持连接。当我在银行工作时,曾经有一个完整的 MITM 代理,有时会无缘无故地花 5 分钟才能打开 Google.com,太烦人了,但在其他 99% 的时间里工作得很好。

  • HTTP/2(以前的 SPDY)和 TLS 1.3 问题。不管你是否相信我,但这些产品在刚推出的头几年就充满了 bug(截至 2020 年仍然存在一些边缘情况)。任何开发人员都应该意识到,没有任何代码在第一次尝试时是完美的,需要一段时间才能消除错误和边缘情况。不幸的是,这些东西确实需要跨系统完美工作,否则哎呀(浏览器、负载平衡器、Web 服务器等)。相信我,当您在组织中需要管理数十或数百个应用程序(在几个不同的堆栈上)时,您不会想成为新协议的早期采用者。

  • Chrome 错误。像所有复杂的软件一样,Chrome 也有缺陷,更重要的是因为它运行速度很快,而且经常故意把事情强加给你。我可以重复 HTTP/2 作为例子,Chrome 是第一个实现的,当然第一次尝试并不完美,所以这里出现了一些错误。Chrome 也是第一个默认启用它的浏览器,当然这会导致弹出窗口不兼容,并且您无法逃脱它。当您遇到奇怪的问题时,请考虑尝试上一个/下一个版本的 Chrome 或其他浏览器。

  • 防毒软件。防病毒软件会过滤进出计算机的所有连接和所有流量。如果您不知道 Windows 防病毒软件的工作原理,它们会拦截所有网络系统调用。它们并非完美无缺,并且可能会严重破坏连接。我可以告诉你,我花了很多时间调试一个影响少数员工的问题,一个软件通过 HTTP 下载配置,这应该需要 1 秒,但对他们来说需要 10 分钟到 2 小时。我们追踪到这个问题是由于赛门铁克防病毒软件导致连接停止(1 KB/s),尝试分析流量或确定是否允许连接时一定是有问题的。然后与支持人员来回尝试修复它或找到不会发生这种情况的设置。