AWS Elastic Load Balancing：初始连接时间极长答案

【问题标题】：AWS Elastic Load Balancing: Seeing extremely long initial connection timeAWS Elastic Load Balancing：初始连接时间极长
【发布时间】：2021-10-23 02:27:32
【问题描述】：

几天来，当通过 ssl 发出任何请求时，我们经常会看到与 ELB 的初始连接时间非常长（15 秒 - 1.3 分钟）。奇怪的是，我只能在 Google Chrome（不是 Safari、Firefox 和 curl）中观察到这一点。

它不会发生在每个请求中，而是大约 50% 的请求。它发生在第一个请求（OPTIONS 调用）中。

我们的设置如下：连接到 node.js 后端的跨区域 ELB（目前在 eu-west-1 的 2 个可用区中）。所有实例都是健康的，一旦请求通过，就会正常处理。目前，系统基本没有负载。 Cloudwatch for ELB 不报告任何后端连接错误，既不报告 SurgeQueue（值 0），也不报告溢出计数。 ELB 指标显示低延迟（

我们有不同的 REST-API 都有这种设置。它发生在所有 ELB 上（每个 ELB 都连接到一个独立的 node.js 后端）。所有这些 ELB 都通过我们的 cloudformation 模板以相同的方式设置。

ELB 也执行我们的 SSL 终止。

什么会导致这种行为？ ELB 是否配置不正确？为什么它只能出现在谷歌浏览器上？

【问题讨论】：

您应该在带有浏览器的机器上安装wireshark，并尝试识别tcp握手中出现延迟的时间点。这似乎很不寻常。
@gboda 很好的发现，可惜它也没有答案。也许我们这里还有一个可以做到的。
奇怪，这里的probably another one 也没有得到答复。奇怪的 Chrome + ELB 交互？
我刚刚创建了一个相同的问题，但不是针对 ELB - 而是针对 ALB here。我们找到了解决方案，但有趣的是，所有症状都与这个问题中的完全相同。

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

【解决方案1】：

我认为这可能是 ELB 配置错误。当我将私有子网放入 ELB 时，我遇到了同样的问题。通过将私有子网更改为公共子网来修复它。见https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-manage-subnets.html

【讨论】：

对于面向公众的 ELB，仅选择公共子网。对于面向私有的 ELB，请仅选择私有子网。

【解决方案2】：

只是为了跟进@Nikita Ogurtsov 的出色回答；我遇到了同样的问题，只是 只是我的一个子网碰巧是私有的，其余的都是公共的。

即使您认为您的子网是公共的，我还是建议您仔细检查路由表，以确保它们所有都有网关。

如果有意义，您可以为所有 LB 子网使用具有网关的单个路由表

VPC/Subnets/(select subnet)/Route Table/Edit

【讨论】：

在我的情况下，子网的 ACL 之一被配置为拒绝所有流量。

【解决方案3】：

对我来说，问题是我的 Classic Load Balancer 中有一个未使用的“可用区”。一旦我删除了不健康和未使用的可用区，“初始连接”中一致的 20 或 21 秒延迟下降到 50 毫秒以下。

注意：您可能需要给它一些时间来更新。我将我的 DNS TTL 设置为 60 秒，因此我会在删除未使用的可用区后的一分钟内看到修复。

【讨论】：

【解决方案4】：

这可能是亚马逊 elb 的问题。 elb 随请求数缩放实例数。您应该在这些时候看到一些请求。亚马逊添加了一些实例以适应负载。这些实例在启动过程中是可访问的，因此您的客户可以获得这些超时。这完全是随机的，所以你应该：

ping elb 以获取所有使用的 ip
在找到的所有 ip 上使用 mtr
关注 CloudWatch
找到一些线索

【讨论】：

【解决方案5】：

解决方案如果您的 DNS 配置为直接命中 ELB -> 您应该减少关联的 TTL（IP、DNS）。 IP 可以随时随 ELB 更改，因此您的流量可能会受到严重损害。

客户端将一些来自 ELB 的 IP 保存在缓存中，这样你就可以解决这些问题。

扩展弹性负载均衡器创建弹性负载均衡器后，您必须将其配置为接受传入流量并将请求路由到您的 EC2 实例。这些配置参数由控制器存储，控制器确保所有负载平衡器都以正确的配置运行。控制器还将监控负载平衡器并管理用于处理客户端请求的容量。它通过利用更大的资源（具有更高性能特征的资源）或更多的单独资源来增加容量。 Elastic Load Balancing 服务将在扩展时更新负载均衡器的域名系统 (DNS) 记录，以便新资源在 DNS 中注册其各自的 IP 地址。创建的 DNS 记录包括 60 秒的生存时间 (TTL) 设置，期望客户端至少每 60 秒重新查找一次 DNS。默认情况下，当客户端执行 DNS 解析时，Elastic Load Balancing 将返回多个 IP 地址，记录在每个 DNS 解析请求中随机排序。随着流量配置文件的变化，控制器服务将扩展负载均衡器以处理更多请求，在所有可用区中均等地扩展。

Best Practices ELB on AWS

【讨论】：

如果条目是ELB别名，则无法在Route53中设置TTL。
是的，但我没有谈论 Route53。当然，Amazon 为自己的 ELB 预先配置了 DNS，否则您将遇到之前出现的错误。
我最近通过将别名记录的 TTL 设置为 60 秒解决了这个问题。

【解决方案6】：

ALB 负载均衡器需要 2 个可用区。如果您使用 Privat/Public/Nat VPC 设置，则所有公有子网都必须连接到 Internet。

【讨论】：

【解决方案7】：

对我来说，问题在于 ALB 指向一个 Nginx 实例，该实例的 DNS 解析器配置错误。这意味着 Nginx 尝试使用解析器，然后超时，然后才真正开始工作。

与负载均衡器本身并没有真正的超级联系，但也许可以帮助某人在他们自己的设置中找出问题。

【讨论】：

【解决方案8】：

还要检查一个安全组。这对我来说是个问题。

【讨论】：

你能详细说明吗？
@MathiasLykkegaardLorenzen 安全组充当您的实例的虚拟防火墙，以控制入站和出站流量。所以请确保它配置正确。不幸的是，我不记得细节了。