DNS Round Robin：浏览器只要在线就坚持一个IP吗？

Question

如果大多数浏览器从 DNS 服务器获得多个 A 记录，它们会如何表现？只要可以访问就坚持使用一个IP（并且只有在IP关闭时才使用另一个）？或者他们总是无缘无故地切换？

如果当前的大多数浏览器都坚持使用一个 IP，那么 DNS-RR 作为一种简单的故障转移解决方案对我来说就足够了。

Answer 1

每个浏览器都有自己的处理循环 DNS 的方法，我今天花了一些时间研究这个问题，并将继续更新我的答案，因为我找到了实施证明，这将限制我对暴露其行为的浏览器的答案。

谷歌浏览器

谷歌浏览器（使用 v58）将请求一个地址（A、AAAA、CNAME）的所有主机条目，并将它们放入一个数组（address_list）中。然后，Chrome 将尝试按从头到尾的顺序在每个 IP 地址上打开一个套接字，chrome 不会尝试最快或最近的 IP，它假定第一个 IP（由上游 dns 解析器提供）是最佳 IP。在我的测试中，bind 和 windows dns 服务器为每次查找提供了不同的 IP 顺序，每个 IP 的带宽似乎为 50/50。此功能公开在chrome://net-internals/#events&q=type:SOCKET%20is:active

卷曲 (libcurl/7.54.0)

Curl 也有这个故障转移功能，但--connect-timeout比 chrome 中的默认值要长得多，chrome 会立即进行故障转移，而 Curl 没有。如果您使用 libcurl 并希望在一个 IP 失败的循环 dns 实例中幸存下来（在 chrome 中工作但不在代码中），请务必将此值指定为较低。

DEFAULT_CONNECT_TIMEOUT:0让我觉得这对 curl 来说是不可能的。

* After 149990ms connect time, move on!

在这两种浏览器上，IP 都不是粘性的，它们遵循 DNS 中给出的 TTL，一旦 ttl 过期（chrome 在内部维护这一点，curl 对每个请求进行询问），每次都会执行 ip 选择，如上所述。

这是什么意思？DNS-RR 适用于某些系统，但它不是为故障转移而设计的。您应该期望来自 DNS 查找的所有结果（真实来源）有效并可用于服务流量。有很多方法可以保证IP的可用性，比如虚拟浮动IP、BGP/Routing技巧等，使用它们。

一旦有足够的基础设施可供测试，所有在仅 IPv4 环境中执行的测试将返回双栈结果。

我推测这些变化是 IPv6-Fallback RFC Happy Eyeballs的副作用

更新 一个有用的考虑，RR DNS 只能协助负载平衡，而不是应用程序故障，如果您的一个节点有 503，如果您的流量为 503，您将提供 40-60% 的服务。假设列出的所有 IP 都是有效的工作端点（如果可达）

Answer 2

所有现代浏览器均实现此 https://www.rfc-editor.org/rfc/rfc8305 Happy Eyeballs 版本 2：使用并发实现更好的连接

粗略地说，这意味着将使用连接速度最快的服务器。IPv6 具有更高的优先级。

Answer 3

他们切换 IP，这不是故障转移解决方案。

浏览器让操作系统进行名称解析，例如 Linux 总是随机化 IP 地址，尝试主机 google.com几次。IP 将以随机顺序出现。