任播 DNS 详解

通常情况下，一个 IP 地址对应一台特定的机器，通过一条特定的网络路径到达。任播（anycast）有意打破了这一假设：同一个 IP 地址会同时从全球多个物理上相互独立的地点对外通告，再由互联网路由把每个请求送到在拓扑上离发送方最近的那个通告地点。这里的“最近”不一定是物理距离最近，而是网络路径上最近。

DNS 基础设施为何如此依赖任播

1.1.1.1 和 8.8.8.8 这样的公共解析器都是任播地址。您在东京查询 1.1.1.1，另一个人在柏林查询同一个地址，双方实际连到的是不同的物理服务器，也就是各自网络上最近的那一台，而两边配置里填写的却是完全相同的 IP 地址。正因如此，一个好记的 IP 就能在全球范围内持续提供低延迟，而不是让所有人不论身在何处，都路由到同一个物理数据中心。

• 韧性：某个任播地点下线时，路由会直接转向次近的地点，客户端往往毫无察觉。
• 它并非 DNS 独有，CDN 和其他一些对延迟敏感的服务也采用同样的底层技术。

实际意义

要从任播中获益，您不需要做任何不同的配置。它完全发生在网络路由层，发起查询的应用对此毫无感知。了解它的主要价值在于解释一个现象：大型公共解析器能在全球保持快速、可用，而您不必像选择云数据库或计算实例那样，去挑选某个特定区域的端点。

“拓扑上最近”的背后机制是 BGP

“网络路径上最近”并不是由某种实时测量物理距离的机制决定的。每个通告任播地址的网络，都是通过 BGP 来通告的。BGP 是把互联网上各个独立网络连接起来的路由协议，沿途每台路由器都会按 BGP 自己的度量标准，选出当前看起来最短的那条通往该地址的路径，通常指经过的网络跳数最少，而不是公里数最少。实际中，这通常与物理上的就近大体吻合，但并不完全一致：如果某条路径在 BGP 看来恰好更短，请求偶尔会被路由到稍远一些的地点，尤其是在网络故障或存在特殊对等互联安排的情况下。

为什么任播并不适用于所有场景

任播非常适合单次 DNS 查询与应答这类简短、无状态的交互：即便后续的数据包恰好被路由到与第一个包不同的物理服务器，也没有什么可损失的。但它不适合长时间保持的有状态连接：如果底层网络路径在连接中途发生变化（路由抖动、对等关系调整），一个 TCP 会话就可能被送到与起始端点不同的另一台物理服务器，由于新服务器根本不知道这个连接存在过，连接就会直接中断。这也是任播与 DNS 及其他基于 UDP 的请求-响应协议联系如此紧密，却很少用于长时间运行的数据库连接或视频流的原因之一。