网页资源请求在 Chrome 中停滞了近一分钟答案

【问题标题】：Webpage resource request stalled for nearly a minute in Chrome网页资源请求在 Chrome 中停滞了近一分钟
【发布时间】：2019-08-14 05:44:58
【问题描述】：

长时间停顿后，我的 web 应用上的资源需要将近一分钟才能加载。这种情况始终如一地发生。如下图，这个页面上只有3个请求真正命中了服务器本身，其余的都命中了内存或磁盘缓存。这个问题似乎只发生在 Chrome 上，Safari 和 Firefox 都没有出现这种行为。

我已经在这个 SO question 中实施了Cache-Control: no-store 建议，但问题仍然存在。 request stalled for a long time occasionally in chrome

下面还包括一个示例，说明响应最终进入后的样子。

我的应用托管在 AWS 中的网络负载均衡器后面，该负载均衡器代理运行 nginx 的 EC2 实例和应用本身。

任何想法是什么原因造成的？

【问题讨论】：

为什么同一个资源会有两个请求？
如果您的浏览器只发送有问题的请求，您能否检查是否出现此问题？
与 EC2 实例上的“网络”类型负载均衡器和 nginx 完全相同的问题。直接访问同一个实例时没有问题。将每页请求的资源数量降至 6 以下，但这没有帮助。 Firefox 浏览器没有此类问题。

标签： amazon-web-services google-chrome http

【解决方案1】：

我遇到了完全相同的问题。我们将 Elastic Beanstalk 与网络负载均衡器 (NLB) 结合使用，并在 NLB 处终止 TLS。

我从 AWS 支持得到的反馈是：

当客户端连接到网络负载均衡器上的 TLS 侦听器并且在完成 TLS 握手后未立即发送数据时，可能会出现此问题。根本原因是处理新连接的边缘情况。请注意，仅当 TLS 侦听器的目标组配置为使用 TCP 协议而未启用代理协议 v2 时，才会发生这种情况

他们现在正在努力解决这个问题。不知何故，这个问题只有在您使用 Chrome 浏览器时才会注意到。

与此同时，您有以下 2 个选项作为解决方法：

在目标组上启用代理协议 v2 或
将目标组配置为使用 TLS 协议将流量路由到目标

【讨论】：

【解决方案2】：

我知道这是一个迟到的答案，但我是为寻求解决方案的人写的。

TL;DR：在我的例子中，启用 NLB 的 cross-zone load balancing 属性解决了这个问题。

通过使用 WireShark 进行调查，我发现 Chrome 与两个不同的 IPv4 地址进行通信。向其中一个发送数据包总是成功，而向另一个发送数据包总是失败。实际上这两个地址委托了两个可用区。

如果选择 NLB，则默认禁用跨区域负载均衡（相反，默认启用 ALB 的相同属性）。假设有两个 AZ； AZ-1 / AZ-2。当您将两个 AZ 附加到 NLB 时，每个 AZ 都有一个节点。

节点属于 AZ-1 只是将流量路由到也属于 AZ-1 的实例。 AZ-2 实例被忽略。我的普通应用（托管在 Fargate 上）在 AZ-2 中只有一个应用服务器（ECS 任务），因此 AZ-1 中的 NLB 节点无法将流量路由到任何地方。

我不熟悉 TCP/IP 或浏览器的实现，但据我了解，您的浏览器会在 DNS 查找后以某种方式选择实际的 IP 地址。如果在上述情况下选择了 AZ-2 节点，则一切正常，但如果选择了 AZ-1，则您的浏览器开始停止。可能 Chrome 有随机选择 ip 的策略，而 Safari 或 Firefox 有粘性，所以问题只出现在 Chrome 上。

启用cross-zone load balancing 后，AZ-2 上的 ECS 任务从 AZ-1 NLB 节点可见，并且在 Chrome 浏览器上也可以正常工作。

（请随时纠正我糟糕的英语。谢谢！）

【讨论】：

【解决方案3】：

我发现有两件事可能导致延迟：

1) CDN 的使用
如果加载缓慢的资源是从 CDN（内容交付网络）加载的，您应该尝试将它们下载到服务器并直接交付。
特别是如果您使用 http2，这可能会显着提高速度，但使用 http1 也是如此。我没有使用 AWS 的经验，所以我不知道默认情况下是如何提供服务的。
如果资源是从 CDN 加载的，则屏幕截图中未清楚显示，但由于它与脚本有关，我认为这是一个合理的假设。

2) Chrome 的资源调度器
一般说明：https://blog.chromium.org/2013/04/chrome-27-beta-speedier-web-and-new.html
自文章发布以来，此调度程序可能甚至很可能已更改，但至少显示在您的屏幕截图中。
我认为，如果您借助 https://www.webpagetest.org 和 chrome web 工具优化页面，您可以解决调度程序的任何问题，还可以解决有关速度的其他问题，也许还有其他问题。这是链接：https://developers.google.com/web/tools/

编辑
3) 代理问题
通常，由于代理服务器，chrome 可能存在问题或延迟的原因。在锁定日志文件之前无法知道详细信息，也许您必须调整日志文件甚至生成并且日志级别足以告诉您任何问题（级别 Warning 甚至 @987654325 @)。

【讨论】：

【解决方案4】：

监控 chrome net-export 日志后，我似乎遇到了这个问题：https://bugs.chromium.org/p/chromium/issues/detail?id=447463。

我仍然没有解决问题的方法。

【讨论】：

我在答案中添加了一部分，并认为最好的方法是使用我链接的工具优化页面，但检查服务器和代理的日志也可能会有所帮助。除此之外，我认为绕过你到目前为止得到的唯一答案是很奇怪的——一般来说，有些问题是在对话中解决的，而不是通过忽略——对不起，只是我的 2 美分。