domain-name-system – DNS Round Robin：只要在线,浏览器就会粘贴到一个IP上吗？

如果大多数浏览器从DNS服务器获得多个A记录,它们的行为如何？只要可以到达一个IP就可以坚持下去(如果IP已关闭,只能使用另一个IP)？或者他们是否无缘无故地切换？

如果当前大多数浏览器都坚持使用一个IP,那么DNS-RR就足以作为一个简单的故障转移解决方案.

解决方法

每个浏览器都有自己的处理循环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为：active

卷曲(libcurl / 7.54.0)

Curl也具有此故障转移功能,但–connect-timeout比chrome中的默认值长得多,chrome会立即故障转移,而Curl则不会.如果您使用libcurl并希望在一个IP失败的循环dns实例中存活(使用chrome但不在代码中),请确保将此值指定为更低.

DEFAULT_CONNECT_TIMEOUT:0让我觉得卷曲是不可能的.

* 149990ms连接时间后,继续！

在两个浏览器上,IP都不是粘性的,它们遵循DNS中给出的TTL,并且一旦ttl到期(chrome在内部维护,curl询问每个请求),每次执行ip选择如上所述.

这是什么意思？
DNS-RR适用于某些系统,但它不适用于故障转移.您应该期望来自DNS查找的所有结果都是(事实来源)有效且可用于提供流量.有许多方法可以确保IP可用性,例如虚拟浮动IP,BGP /路由技巧等.使用它们.

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

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

更新一个有用的考虑因素,RR DNS只能协助负载平衡,而不是应用程序故障,如果您的一个节点有503,如果您的流量503s,您将提供40-60％.假设所列出的所有IP都是有效的工作端点(如果可达)