如果大多数浏览器从 DNS 服务器获得多个 A 记录，它们会如何表现？它们会一直使用一个 IP 吗？（只有当 IP 不可用时才使用另一个 IP）？还是它们会无缘无故地一直切换？
如果大多数当前浏览器都坚持使用一个 IP，那么 DNS-RR 对我来说就足以作为一个简单的故障转移解决方案。
答案1
每个浏览器都有自己的处理循环 DNS 的方法，今天我花了一些时间研究这个问题，并将继续更新我的答案，因为我找到了实施的证据，这将限制我的答案到暴露其行为的浏览器。
谷歌浏览器
Google Chrome（使用 v58）将请求地址（A、AAAA、CNAME）的所有主机条目并将它们放入数组中（地址列表）。然后，Chrome 将尝试按从第一个到最后一个的顺序在每个 IP 地址上打开套接字，Chrome 不会尝试最快或最近的 IP，它假定第一个 IP（由上游 DNS 解析器提供）是最佳 IP。在我的测试中，bind 和 windows dns 服务器在每次查找时给出不同的 IP 顺序，为每个 IP 提供似乎 50/50 的带宽分配。此功能在chrome://net-internals/#events&q=type:SOCKET%20is:active
Curl（libcurl/7.54.0）
Curl 也具有此故障转移功能，但--connect-timeout比 Chrome 中的默认值长得多，Chrome 会立即进行故障转移，而 Curl 则不会。如果您使用 libcurl 并希望在一个 IP 发生故障的循环 DNS 实例中生存下来（在 Chrome 中有效但在代码中无效），请确保将此值指定得较低。
默认连接超时：0这让我认为使用 curl 是不可能的。
* After 149990ms connect time, move on!
双方浏览器，IP 没有黏，它们遵循 DNS 中给出的 TTL，一旦该 TTL 过期（chrome 在内部维护此，curl 会在每次请求时询问），每次都会执行 ip 选择，如上所述。
这是什么意思？DNS-RR 适用于某些系统，但它不是为故障转移而设计的。您应该期望 DNS 查找的所有结果（真实来源）都是有效的并且可用于服务流量。有很多方法可以确保 IP 可用性，例如虚拟浮动 IP、BGP/路由技巧等。使用它们。
所有测试均在仅在 IPv4 环境中执行，一旦有足够的基础设施可供测试，就会返回双栈结果。
我猜测这些变化是 IPv6-Fallback RFC 的副作用快乐眼球
更新 一个有用的考虑因素是，RR DNS 只能帮助实现负载平衡，而不能帮助解决应用程序故障，如果您的某个节点出现 503，则您的流量为 503，您将提供 40-60% 的服务。假设列出的所有 IP 都是有效的工作端点，如果可达
答案2
所有现代浏览器都实现了这个 https://www.rfc-editor.org/rfc/rfc8305 Happy Eyeballs 版本 2：使用并发实现更好的连接
大致意思是将使用连接速度最快的服务器。IPv6 具有更高的优先级。
答案3
请参阅我的问题（及答案）：浏览器如何处理多个 IP。
简而言之 - 循环 DNS 根本无法提高可用性。浏览器选择一个 IP 并坚持使用它，即使它没有响应。（使用 FF 和 chrome 检查）。
一旦浏览器 DNS 缓存过期，主机名就会再次解析并重复该过程，无论 IP 是否应答。
对于基本的 HA，您可以使用动态 DNS 或各种基于 IP 的方法。
编辑：当无法访问的主机充当“黑洞”时，将发生此行为。如果主机主动拒绝传入连接，浏览器将尝试一个 IP，拒绝并立即使用另一个 IP，因此它将很好地进行故障转移。
答案4
他们切换 IP，这不是故障转移解决方案。
浏览器让操作系统进行名称解析，例如 Linux 总是随机化 IP 地址，尝试托管 google.com多次。IP 将以随机顺序出现。