dns - 浏览器无法在持久连接上重新协商 DNS
问题描述
我正在使用每 5 秒刷新一次（轮询）的实时仪表板（Angular Web 应用程序）调查一个场景。API 位于 Azure 流量管理器后面，如果主要区域发生故障，它将故障转移到第二个区域。请记住，Azure 流量管理器在 DNS 级别工作。
我面临的问题是，即使在流量管理器故障转移后，浏览器仍保持与主要区域的持久连接。请求最初以 503s 失败，但随后继续以 502s 失败。由于请求比保持活动超时更频繁地发生，因此永远不会再次执行 DNS 查找。这会导致浏览器继续向故障区域发出请求。
无论如何要明确终止连接以强制进行 DNS 查找？到目前为止，我发现的唯一方法是停止发出请求 2 分钟，或者关闭并重新打开浏览器。对于应该不插手且始终保持新鲜的仪表板来说，这也不是一个可接受的解决方案。
有趣的是，在让浏览器故障转移到次要区域后，如果我重新启动主要区域，浏览器将在大约一分钟后自动切换回主要区域。这告诉我，当服务正常运行时，连接尊重 DNS TTL，但在服务器不可用时则不然。这对我来说毫无意义，为什么浏览器会在找不到单个 IP 时永远锁定它。
关于使用流量管理器为 Web 应用程序实现地理冗余故障转移，我是否遗漏了什么？在我看来，在浏览器重新协商 IP 到故障转移服务器之前，用户必须在任何情况下停止发出请求 2 分钟，这对我来说似乎很奇怪。是否有望启用 keep-alive 以真正支持近乎即时的故障转移？
这是描述此场景的图表：
图表
解决方案
通常，Azure 流量管理器在 DNS 级别工作。客户端直接连接到服务端点，而不是通过流量管理器。流量管理器无法跟踪单个客户端，也无法实现“粘性”会话。
- 对于初始 DNS 查找性能影响，您可以在此处 1和此处 2找到解释详细信息
DNS 名称解析速度很快，结果会被缓存。初始 DNS 查找的速度取决于客户端用于名称解析的 DNS 服务器。通常，客户端可以在约 50 毫秒内完成 DNS 查找。查找结果在 DNS 生存时间 (TTL) 期间缓存。流量管理器的默认 TTL 为 300 秒。
每条 DNS 记录的 TTL 值决定了缓存的持续时间。较短的值会导致更快的缓存到期，而较长的值意味着将流量从失败的端点引导出去可能需要更长的时间。流量管理器允许您将 TTL 配置为低至 0 秒和高达 2,147,483,647 秒。您可以选择最能平衡您的应用程序需求的值。
- 和上面一样，如果你想让 DNS 查找更快，你可以将 TTL 值设置得尽可能低。建立连接后，客户端会持续连接到选定的端点，直到端点通过健康检查变得不健康。
- 您可以启用和禁用流量管理器配置文件和端点。但是，由于流量管理器自动化设置和流程，端点状态也可能发生变化。. 在此处获取更多详细信息。
- 对于地理路由方法，
返回根据查询请求 IP映射到服务地理位置的端点。如果该端点不可用，则不会选择另一个端点进行故障转移，因为地理位置只能映射到配置文件中的一个端点（更多详细信息在FAQ中）。作为一种最佳实践，在使用地理路由时，我们建议客户使用嵌套流量管理器配置文件，并将多个端点作为配置文件的端点。