Loading... # 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.6 ``` ## 3. 工作原理 ```mermaid 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. 理论流程 ```mermaid 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 命令行工具 **行为特征**： - 第一次可能不准确 - 第二次运行时总是选择最近的服务器 - 行为正确且可预测 ```mermaid 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） - 不会自动切换到其他在线服务器 ```mermaid 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 解析流程 1. 客户端发起 DNS 查询 2. DNS 服务器返回所有 A 记录 3. 客户端根据内部策略选择一个 IP 4. 建立连接 ## 2. 客户端策略差异 - **Safari/curl**：智能选择，基于 RTT 优化 - **Chrome/Firefox**：随机选择，缓存结果 - **Cloudflare**：IP 哈希，固定路由 ## 3. 故障检测机制 浏览器通过连接超时和重试机制实现故障检测。Cloudflare 在 Round Robin DNS 模式下似乎未实现健康检查。 *** ## 参考资料 1. [Understanding Round Robin DNS - by Zsolt Ero](https://blog.hyperknot.com/p/understanding-round-robin-dns) 2. [RFC 8305 - Happy Eyeballs](https://datatracker.ietf.org/doc/html/rfc8305) 3. [RFC 6724 - Default Address Selection](https://datatracker.ietf.org/doc/html/rfc6724) 4. [Cloudflare 零宕机故障转移文档](https://developers.cloudflare.com/fundamentals/basic-tasks/protect-your-origin-server/#zero-downtime-failover) 最后修改：2026 年 01 月 16 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏