相关疑难解决方法(0)

从阅读来看，似乎不推荐 DNS 故障转移，因为 DNS 不是为它设计的。但是，如果您在不同子网上有两个 Web 服务器托管冗余内容，那么还有哪些其他方法可以确保在一台服务器出现故障时将所有流量路由到实时服务器？

对我来说，似乎 DNS 故障转移是这里唯一的故障转移选项，但共识是这不是一个好的选择。然而像 DNSmadeeasy.com 这样的服务提供了它，所以它一定有它的优点。任何意见？

当浏览器获取给定主机名（例如 ip1 和 ip2）的多个 A 记录并且其中一个无法访问时，有人可以指导我了解有关确切浏览器行为的信息。

我对确切的细节感兴趣，例如（但不限于）：

1. 浏览器会从操作系统获得 2 个 IP，还是只会获得一个？
2. 浏览器将首先尝试哪个 ip（随机或总是第一个）？现在，假设浏览器以失败的 ip1 启动
3. 浏览器会尝试多长时间 ip1 ？
4. 如果用户在等待 ip1 时点击“停止”，然后点击刷新
   • 浏览器会尝试哪个 IP？
5. 当它超时时会发生什么 - 它会开始尝试 ip2 还是给出错误？（如果出现错误，当用户点击刷新时浏览器将尝试哪个 ip）。
6. 当用户点击刷新时，任何浏览器都会尝试新的 DNS 查找吗？

现在让我们假设浏览器首先尝试使用 ip2。

1. 对于下一个页面请求，浏览器是否仍然使用ip2，或者它可能会随机切换ips？
2. 浏览器在其缓存中保留 IP 多长时间？
3. 当浏览器发送一个新的 DNS 请求并获得相同的 ips 时，它会继续使用相同的已知正在工作的 IP，还是该过程从头开始，它可能会尝试两者中的任何一个？

当然，这一切都可能取决于浏览器，也可能因版本和平台而异，我很乐意提供最多的细节。

这样做的目的 - 我试图了解当使用基于循环 DNS 并且其中一台主机出现故障时，用户会体验到什么。

拜托，我不是在问 DNS 负载平衡有多糟糕，请不要回答“不要这样做”、“这是一个坏主意”、“您需要心跳/代理/BGP/任何东西”等等。

通常，像 Amazon 的 Elastic Load Balancers 这样的负载均衡器使用具有多个 A 记录的 DNS 记录集来提供多个负载均衡器实例，这些实例可以处理到请求端点的流量：

$ dig +short my-fancy-elb.us-east-1.elb.amazonaws.com
10.0.1.1
10.0.1.2

如果我尝试以详细模式卷曲此 URL，我会注意到curl似乎对两个 IP 地址进行循环尝试：

$ curl -ivs http://my-fancy-elb.us-east-1.elb.amazonaws.com | grep -i 'connected'
* Connected to my-fancy-elb.us-east-1.elb.amazonaws.com (10.0.1.1)
$ curl -ivs http://my-fancy-elb.us-east-1.elb.amazonaws.com | grep -i 'connected'
* Connected to my-fancy-elb.us-east-1.elb.amazonaws.com (10.0.1.2)

curl对记录集中描述的 A 记录进行循环的事实是由curl二进制本身完成的还是 Linux 内核为它做的？

TCP 存在于第 4 层，DNS 存在于第 7 层，所以我想各个二进制文件和库必须实现自己的负载平衡和故障转移：获取给定域名的 DNS 记录集并选择一个 TCP 地址以从那个集合连接到。

我可以合理地期望编程语言、浏览器和像 curl 这样的库会为我在 A 记录上进行负载平衡和故障转移吗？