浏览器无法在持续连接上重新协商 DNS

Question

我\xe2\x80\x99m 调查一个带有实时仪表板（Angular Web 应用程序）的场景，该仪表板每 5 秒刷新一次（轮询）。该 API 位于 Azure 流量管理器后面，如果主要区域出现故障，该管理器将故障转移到第二个区域。请记住，Azure 流量管理器在 DNS 级别工作。

\n\n

我面临的问题是，即使在流量管理器发生故障转移后，浏览器仍保持与主要区域的持久连接。请求最初失败并显示 503 秒，但随后继续失败并显示 502 秒。DNS 查找永远不会再次执行，因为请求发生的频率比保持活动超时的频率更高。这会导致浏览器继续向失败的区域发出请求。

\n\n

有没有办法明确终止连接以强制进行 DNS 查找？到目前为止我发现的唯一方法是停止发出请求 2 分钟，或者关闭并重新打开浏览器。对于应该不受干扰且始终保持新鲜的仪表板来说，这两种解决方案都不是可接受的解决方案。

\n\n

有趣的是，在让浏览器故障转移到次要区域后，如果我重新启动主要区域，浏览器将在大约一分钟后自动切换回主要区域。这告诉我，当服务正常运行时，连接会遵守 DNS TTL，但当服务器不可用时，则不会。这对我来说毫无意义，为什么浏览器会在找不到\xe2\x80\x99s 时永远锁定单个IP。

\n\n

对于使用流量管理器为 Web 应用程序实施地理冗余故障转移，我是否缺少某些内容？在我看来，很奇怪的是，在任何情况下，用户都必须停止发出请求 2 分钟，然后浏览器才能将 IP 重新协商到故障转移的服务器。是否期望关闭保持活动以真正支持近乎即时的故障转移？

\n\n

下面是描述此场景的图表：\n图表\n

\n

Answer 1

通常，Azure 流量管理器在 DNS 级别工作。客户端直接连接到服务端点，而不是通过流量管理器。流量管理器无法跟踪各个客户端，也无法实现“粘性”会话。

\n

\n
• 对于初始 DNS 查找性能影响，您可以在此处 1和此处 2找到详细说明
\n

\n

\n

DNS 名称解析速度很快并且结果会被缓存。初始 DNS 查找的速度取决于客户端用于名称解析的 DNS 服务器。通常，客户端可以在 ~50\nms 内完成 DNS 查找。查找结果将在 DNS\n生存时间 (TTL) 期间进行缓存。流量管理器的默认 TTL 为 300\n秒。

\n

每个 DNS 记录的 TTL 值决定缓存的持续时间。较短的值会导致更快的缓存过期，而较长\n的值意味着\n将流量从失败的端点引出可能需要更长的时间。流量管理器允许您将 TTL 配置为\n低至 0 秒、高达 2,147,483,647 秒。您可以\n选择最能平衡应用程序需求的值。

\n

\n

\n
• 与上面一样，如果您希望 DNS 查找更快，则可以将 TTL 值设置得尽可能低。连接建立后，客户端将持续连接到选定的端点，直到该端点通过运行状况检查发现运行状况不佳。
\n
• 您可以启用和禁用流量管理器配置文件和端点。但是，流量管理器自动化设置和流程也可能导致端点状态发生变化。。在此获取更多详细信息。
\n
• 对于地理路由方法，
\n

\n

\n

返回映射为根据查询请求 IP\xe2\x80\x99s提供地理位置服务的终结点。如果该终结点不可用，\n将不会选择其他终结点进行故障转移，因为\n地理位置只能映射到配置文件中的一个终结点\n（更多详细信息请参阅常见问题解答）。作为一种最佳实践，\n在使用地理路由时，我们建议客户使用嵌套的 TrafficManager 配置文件，并将多个终结点作为\n配置文件的终结点。

\n

\n