Round Robin DNS 工作原理与实践分析
一、概述
1. 背景
Round Robin DNS 是一种简单而优雅的负载均衡解决方案。通过在 DNS 记录中配置多个 IP 地址，可以让流量自动分散到不同的服务器上。这种方法无需昂贵的负载均衡设备，适用于需要全球分布式部署的服务。
2. 核心问题
虽然 Round Robin DNS 的概念简单，但实际使用中存在几个关键问题：
- 客户端如何选择服务器
- 如何实现就近接入（低延迟）
- 服务器离线时如何故障转移
- CDN 服务器的行为是否符合预期
3. 实验设计
作者在全球部署了 3 个 VPS（美国、欧洲、新加坡），分别配置了直连和 Cloudflare 代理的 A 记录，通过不同客户端测试其选择行为。
二、Round Robin DNS 基本原理
1. 传统 DNS 配置
传统的单一 A 记录配置如下：
域名 类型 TTL 值
rr-direct.example.com A 300 5.223.46.55这种配置下，所有请求都指向单一服务器。
2. Round Robin DNS 配置
Round Robin DNS 配置多个 A 记录指向同一域名：
域名 类型 TTL 值
rr-direct.example.com A 300 5.223.46.55
rr-direct.example.com A 300 1.2.3.4
rr-direct.example.com A 300 9.8.7.63. 工作原理
graph LR
A[客户端] -->|1. DNS 查询| B[DNS 服务器]
B -->|2. 返回 IP 列表<br/>5.223.46.55<br/>1.2.3.4<br/>9.8.7.6| A
A -->|3. 客户端选择| C{选择策略}
C -->|Ping 测试| D[延迟最低]
C -->|随机选择| E[第一个 IP]
C -->|IP Hash| F[固定 IP]
D --> G[连接服务器 1]
E --> H[连接服务器 2]
F --> I[连接服务器 3]
三、理论标准：RFC 8305 Happy Eyeballs
1. 标准概述
RFC 8305（Happy Eyeballs）定义了客户端在连接前应如何对地址进行排序。关键规则是：
如果客户端是有状态的，并且具有访问每个地址的路由的历史往返时间（RTT），它应该在规则 8 和 9 之间添加目标地址选择规则，优先选择具有较低 RTT 的地址。
2. 理论流程
sequenceDiagram
participant C as 客户端
participant D as DNS 服务器
participant S1 as 服务器 1（近）
participant S2 as 服务器 2（远）
participant S3 as 服务器 3（极远）
C->>D: DNS 查询
D-->>C: 返回 IP 列表
Note over C: 检查服务器在线状态
C->>S1: Ping/连接测试
C->>S2: Ping/连接测试
C->>S3: Ping/连接测试
Note over C: 按 RTT 排序
C->>S1: 连接延迟最低的服务器
3. 理论总结
- 检查服务器在线/离线状态
- 对在线服务器按 Ping 时间排序
- 选择延迟最低的服务器
四、客户端行为实测
1. 测试环境
- 客户端位置：欧洲
- 服务器分布：美国（绿色）、欧洲（蓝色）、新加坡（红色）
- 预期：应该连接到延迟最低的欧洲服务器（蓝色）
2. Chrome 浏览器
行为特征：
- 启动时随机选择一个服务器
- 选择后会保持连接（缓存）
- 数小时后才会重新评估
- 可能连接到延迟最高的服务器（如新加坡）
问题：不考虑地理位置和延迟，可能导致性能极差。
3. Firefox 浏览器
行为特征：
- 与 Chrome 类似
- 启动时随机选择
- 重启浏览器后重新随机选择
问题：同样不考虑延迟。
4. Safari 浏览器
行为特征：
- 总是正确选择最近的欧洲服务器
- 服务器离线后能快速恢复到正确选择
- 表现最符合理论预期
优势：实现了智能的延迟感知选择。
5. curl 命令行工具
行为特征：
- 第一次可能不准确
- 第二次运行时总是选择最近的服务器
- 行为正确且可预测
graph LR
A[curl 第一次请求] --> B{DNS 结果顺序}
B --> C[使用第一个 IP]
C --> D[测量 RTT]
D --> E[curl 第二次请求]
E --> F[选择最低 RTT 的 IP]
五、Cloudflare 行为分析
1. 行为特征
正常情况：
- 根据客户端 IP 哈希选择服务器
- 一旦选择后保持固定（类似 client_ip_hash modulo server_num）
- 每个客户端 IP 总是连接到同一个服务器
- 不考虑延迟和地理位置
问题示例：
- 家庭 IP 固定连接到美国服务器
- 使用移动热点后固定连接到欧洲服务器
- 全球各地的 VPS 连接到随机位置的服务器
2. 故障转移问题
严重缺陷：Cloudflare 不会检测服务器离线状态。
- 服务器离线后，Cloudflare 继续将请求发送到该服务器
- 返回 521 错误（Web Server Is Down）
- 不会自动切换到其他在线服务器
sequenceDiagram
participant C as 客户端
participant CF as Cloudflare
participant S1 as 服务器 1（离线）
participant S2 as 服务器 2（在线）
C->>CF: 请求
Note over CF: 根据 IP Hash<br/>选择服务器 1
CF->>S1: 转发请求
S1-->>CF: 连接失败/超时
CF-->>C: 521 错误
Note over CF: 不尝试服务器 2
3. 与标准对比
根据 Cloudflare 官方文档，理论上应该支持零宕机故障转移，但实际测试显示 Round Robin DNS 配置下无法正常工作。
六、故障转移能力对比
1. 服务器离线场景
当美国服务器被关闭后，各客户端表现：
| 客户端 | 故障检测 | 自动切换 | 切换速度 |
|---|---|---|---|
| Chrome | 支持 | 支持 | < 1 秒 |
| Firefox | 支持 | 支持 | < 1 秒 |
| Safari | 支持 | 支持 | < 1 秒 |
| curl | 支持 | 支持 | 立即 |
| Cloudflare | 不支持 | 不支持 | N/A |
2. 浏览器故障转移能力
所有浏览器都能在服务器离线时快速切换到其他服务器。作者测试发现，即使在加载过程中关闭服务器，Safari 也能在 1 秒内完成切换。
3. Cloudflare 的不足
- 无法检测后端服务器状态
- 固定的路由策略导致单点故障
- 与官方文档描述的零宕机故障转移不符
七、实践建议
1. 直连 Round Robin DNS
优点：
- 免费，任何 DNS 提供商都支持
- 浏览器和 curl 都能正确处理故障转移
- Safari 能实现智能的延迟优化
缺点：
- Chrome 和 Firefox 的随机选择可能导致性能问题
- 依赖客户端实现
2. 使用 Cloudflare 代理
优点：
- 提供 CDN 加速和安全防护
- 全球边缘节点
缺点：
- 不支持 Round Robin DNS 的故障转移
- 固定路由不考虑延迟
- 可能比直连更慢
3. 最佳实践建议
- 如果需要故障转移：使用直连 Round Robin DNS
- 如果延迟敏感：不依赖 Chrome/Firefox 的自动选择
- 如果使用 Cloudflare：需要额外的负载均衡解决方案（非 Round Robin DNS）
八、技术细节总结
1. DNS 解析流程
- 客户端发起 DNS 查询
- DNS 服务器返回所有 A 记录
- 客户端根据内部策略选择一个 IP
- 建立连接
2. 客户端策略差异
- Safari/curl：智能选择，基于 RTT 优化
- Chrome/Firefox：随机选择，缓存结果
- Cloudflare：IP 哈希，固定路由
3. 故障检测机制
浏览器通过连接超时和重试机制实现故障检测。Cloudflare 在 Round Robin DNS 模式下似乎未实现健康检查。