dns - 浏览器无法在持久连接上重新协商 DNS

Question

我正在研究一个带有每 5 秒刷新一次(轮询)的实时仪表板(Angular Web 应用程序)的场景。 API 位于 Azure 流量管理器之后，如果主要区域发生故障，它将故障转移到第二个区域。请记住，Azure 流量管理器在 DNS 级别工作。

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

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

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

关于使用流量管理器为 Web 应用程序实现地理冗余故障转移，我是否遗漏了什么？对我来说，在浏览器重新协商 IP 到故障转移服务器之前，用户在任何情况下都必须停止发出请求 2 分钟，这对我来说似乎很奇怪。是否希望关闭保持连接以真正支持近乎即时的故障转移？

这是描述此场景的图表:
Diagram

Answer 1

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

对于初始 DNS 查找性能影响，您可以找到详细说明 here1和 here2

DNS name resolution is fast and results are cached. The speed of theinitial DNS lookup depends on the DNS servers the client uses for nameresolution. Typically, a client can complete a DNS lookup within ~50ms. The results of the lookup are cached for the duration of the DNSTime-to-live (TTL). The default TTL for Traffic Manager is 300seconds.

The TTL value of each DNS record determines the duration ofthe cache. Shorter values result in faster cache expiry and Longervalues mean that it can take longer to direct traffic away from afailed endpoint. Traffic Manager allows you to configure the TTL aslow as 0 seconds and as high as 2,147,483,647 seconds. You couldchoose the value that best balances the needs of your application.

像上面一样，如果你想要更快的 DNS 查找，你可以将 TTL 值设置得尽可能低。建立连接后，客户端将持续连接到选定的端点，直到端点通过健康检查不健康为止。

您可以启用和禁用流量管理器配置文件和端点。然而，端点状态的变化 也可能由于流量管理器 而发生自动化设置和流程。 .获取更多详情 here .

地理 routing method ,

The endpoint mapped to serve the geographic location based on thequery request IP’s is returned. If that endpoint is unavailable,another endpoint will not be selected to failover to, since ageographic location can be mapped only to one endpoint in a profile(more details are in the FAQ). As a best practice, when usinggeographic routing, we recommend customers to use nested TrafficManager profiles with more than one endpoint as the endpoints of theprofile.