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

Question

我正在调查一个带有实时仪表板（Angular web app）的场景，每5秒刷新一次（轮询）。 API位于Azure流量管理器后面，如果主区域发生故障，它将故障转移到第二个区域。请记住，Azure Traffic Manager在DNS级别工作。

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

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

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

我是否缺少一些关于使用Traffic Manager为Web应用程序实现georedundant故障转移的东西？对我来说，在浏览器重新协商IP到故障转移服务器之前，用户必须在任何情况下停止发出2分钟的请求，这似乎很奇怪。是否有望将保持活动转变为真正支持即时故障转移？

这是一个描述这种情况的图表：Diagram

Answer 1

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

• 对于初始DNS查找性能影响，您可以找到解释详细信息here1和here2

DNS名称解析速度快，结果缓存。初始DNS查找的速度取决于客户端用于名称解析的DNS服务器。通常，客户端可以在~50毫秒内完成DNS查找。查找结果将在DNS生存时间（TTL）的持续时间内进行缓存。 Traffic Manager的默认TTL为300秒。

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

• 如上所述，如果您希望更快地进行DNS查找，可以将TTL值设置得尽可能低。建立连接后，客户端将持续连接到所选端点，直到端点通过运行状况检查不健康为止。
• 您可以启用和禁用Traffic Manager配置文件和端点。但是，由于Traffic Manager自动设置和流程，端点状态也可能发生变化。获取更多详细信息here。
• 对于地理routing method，

将返回根据查询请求IP映射为服务地理位置的端点。如果该端点不可用，则不会选择另一个端点进行故障转移，因为地理位置只能映射到配置文件中的一个端点（更多详细信息位于FAQ中）。作为最佳实践，在使用地理路由时，我们建议客户使用具有多个端点的嵌套流量管理器配置文件作为配置文件的端点。