目录

1. 什么是 Anycast？—— 一个简单的比喻
2. Anycast 的工作原理
3. Anycast vs. Unicast vs. Multicast vs. Broadcast
4. Anycast 的核心优势
5. Anycast 的常见应用场景
6. Anycast 的潜在缺点与挑战
7. 如何实现 Anycast？—— 技术要点
8. 动手实验：用 Docker 和 BGP 模拟简单的 Anycast DNS

什么是 Anycast？—— 一个简单的比喻

想象一下，你在中国的北京，想查询天气预报，你打开手机地图，输入“天气”，你的手机会向网络发出一个请求：“谁能告诉我北京的天气？”

• 传统方式（Unicast，单播）：手机会连接到北京唯一的气象服务器，如果这个服务器正在维护或离线,你就查不到天气了。
• Anycast（任意播）方式：气象局在全球部署了多个服务器，比如在北京、上海、纽约，这些服务器都拥有同一个虚拟 IP 地址（106.0.150）。

当你发出查询请求时，互联网的路由系统会自动帮你找到地理位置上最近、网络延迟最低的那个服务器，在北京，你的请求会被路由到北京的服务器；在上海,则会被路由到上海的服务器。

核心思想：多个不同的物理服务器，共享同一个 IP 地址，用户的请求总是被自动路由到“最佳”的那个服务器上。

Anycast 的工作原理

Anycast 的魔力在于 BGP（边界网关协议） 和 路由选择算法。

1. 宣告相同的 IP 前缀：

   
   （图片来源网络，侵删）
   • 在全球不同地理位置的多个服务器上，配置相同的 Anycast IP 地址（0.113.10）。
   • 每个服务器所在的本地网络，都会通过 BGP 协议向全球互联网路由表宣告一个路由条目，告诉全世界：“通往 0.113.10/32（或一个网段）的最佳路径，就是我这里。”

2. 路由器的“最短路径优先”：

   • 全球的路由器（ISP、骨干网）会收到来自多个服务器的 BGP 宣告。
   • 路由器会根据 BGP 的选路原则（如 AS_PATH 路径最短、本地偏好值最高等），计算出到达这个 Anycast IP 的“最佳”或“的路径,并将其添加到自己的路由表中。
   • 这就像在地图上，每个城市都告诉你“到我这里来最快”，而你的手机（路由器）会选择那条看起来最快的路。

3. 流量自动汇聚：

   • 当一个用户（比如在北京）发起请求到 0.113.10 时，数据包会按照北京本地路由器的“最佳路径”被发送。
   • 这个“最佳路径”很可能就是指向北京的那个 Anycast 服务器,因为网络延迟最低。
   • 同理，一个纽约用户的请求会自然地被路由到纽约的那个 Anycast 服务器。

关键点：Anycast 本身不是一个协议，而是一种网络架构或服务部署策略，它依赖于 BGP 和现有的互联网路由基础设施来实现。

Anycast vs. Unicast vs. Multicast vs. Broadcast

为了更好地理解，我们用一个表格来对比这四种“播”的方式：

简单区分：

• Unicast：我发信给张三。
• Broadcast：我在办公室大喊一声，所有人都听到了。
• Multicast：我给“项目组”邮件列表发一封邮件，组内成员都收到了。
• Anycast：我打电话给“公司客服热线”，系统自动将我转接到最近的客服中心。

Anycast 的核心优势

1. 高可用性 和冗余：

   即使某一个 Anycast 节点（如东京的服务器）发生故障或断开连接，全球路由表会自动更新，不再将流量路由到该节点，用户的请求会无缝地切换到下一个“最佳”节点（如首尔的服务器）,服务几乎不受影响。

2. 低延迟 和高性能：

   流量总是被路由到地理上最近或网络延迟最低的节点，这极大地减少了用户等待响应的时间,提升了用户体验。

3. 负载均衡：

   流量会根据用户的地理位置和互联网拓扑结构，自动分布到各个可用的节点上，实现了天然的、分布式的负载均衡,避免了单点过载。

4. 缓解 DDoS 攻击：

   • 这是 Anycast 一个非常重要的特性，当 DDoS 攻击发生时，攻击流量会从四面八方涌向 Anycast IP。
   • 由于流量被分散到全球的多个节点，每个节点只承受一部分攻击流量，这使得单个节点的带宽和资源压力大大减小，更容易抵御或缓解攻击,攻击者甚至很难确定攻击目标的确切物理位置。

5. 简化运维：

   从用户的角度看，只有一个 IP 地址，你可以在全球范围内轻松地添加、移除或维护节点,而无需改变用户的配置。

Anycast 的常见应用场景

Anycast 的优势使其在以下场景中非常流行：

1. 内容分发网络：

   这是 Anycast 最经典的应用，像 Akamai、Cloudflare 这样的 CDN 服务商在全球部署了成千上万个边缘服务器（PoP），当用户访问一个使用 CDN 的网站时，图片、视频、JS/CSS 文件等静态资源会从离用户最近的 Anycast 节点获取,速度极快。

2. 公共 DNS 服务：

   • Google Public DNS (8.8.8 / 8.4.4) 和 Cloudflare DNS (1.1.1) 是最著名的例子，它们使用 Anycast 将全球用户的 DNS 查询请求路由到最近的 DNS 服务器，从而提供快速、可靠且抗攻击的解析服务。

3. 大型网络服务：

   • 像 Amazon (AWS)、Microsoft (Azure)、Google Cloud (GCP) 等云服务商，其公共 IP 地址、负载均衡器、部分 API 端点都使用 Anycast 技术,以确保其服务的全球高可用性和低延迟。

4. 根 DNS 服务器：

   互联网的 13 组根 DNS 服务器也使用了 Anycast 技术，这使得整个互联网的 DNS 查询基础架构更加健壮和高效。

Anycast 的潜在缺点与挑战

1. 配置复杂性：

   配置和维护 Anycast 需要深厚的网络知识，特别是对 BGP 的深刻理解，错误的路由配置可能导致流量黑洞（流量丢失）或流量黑洞（所有流量都涌向一个节点）。

2. TCP 连接问题：

   由于 Anycast 的“最佳路径”可能会在网络状况变化时发生改变（另一个路径变得更快），一个 TCP 连接的源路径和响应路径可能不是对称的，这可能会被某些防火墙或中间设备视为“异常”而中断连接,现代操作系统和网络设备对此已有较好的处理。

3. 日志和监控困难：

   因为所有节点共享一个 IP，服务器日志只会显示客户端的 IP，但无法区分流量最初来自哪个物理节点，你需要配合其他技术（如 BGP 边缘路由器日志、客户端 GeoIP 定位）来分析流量来源和分布。

4. BGP 劫持风险：

   互联网的基石 BGP 并非绝对安全，恶意或错误配置的网络运营商可以“宣告”一个比真实路径更优的路由，从而“劫持”本应流向其他 Anycast 节点的流量，这被称为 BGP 劫持，是 Anycast 面临的一个严重安全威胁。

如何实现 Anycast？—— 技术要点

实现 Anycast 主要涉及以下几个层面：

1. IP 地址规划：

   • 通常使用 /32 (IPv4) 或 /128 (IPv6) 的主机路由，这样可以精确控制每个节点的宣告,避免影响整个网段。

2. BGP 配置：

   • 每个节点都需要运行一个 BGP 路由器（如 Quagga, FRR, 或商业路由器）。
   • 配置 BGP 宣告，将 Anycast IP 宣告到上游的 ISP。
   • 可以通过调整 Local Preference (本地偏好值) 来影响流量的倾向性,让某个数据中心承载更多流量。

3. 路由反射器：

   在大型 Anycast 网络中，节点之间不需要建立全互联的 BGP 会话，而是使用路由反射器来分发路由信息,简化拓扑。

4. 负载均衡器：

   在 Anycast 节点内部，通常还需要一个本地的负载均衡器（如 HAProxy, Nginx, AWS ALB/NLB），将来自 Anycast IP 的流量分发到该节点内部的多个后端服务器实例。

动手实验：用 Docker 和 BGP 模拟简单的 Anycast DNS

这个实验将让你在本地环境中直观感受 Anycast 的工作原理，我们将使用 Docker 来模拟两个地理位置不同的 Anycast DNS 服务器，并使用 ExaBGP 来模拟 BGP 路由宣告。

环境准备：

• 安装 Docker 和 Docker Compose。
• 一个可以运行 BGP 工具的 Linux 环境（实验中我们将使用 Docker 容器）。

实验步骤：

1. 创建项目目录和文件

   mkdir anycast-demo
   cd anycast-demo

   创建 docker-compose.yml 文件：

   version: '3.8'
   services:
     # 模拟两个地理位置不同的 DNS 服务器
     dns-server-us:
       image: internetsystemsconsortium/bind9:9.16
       container_name: dns-us
       volumes:
         - ./zone:/etc/bind
       networks:
         anycast-net:
           ipv4_address: 172.20.0.2
     dns-server-jp:
       image: internetsystemsconsortium/bind9:9.16
       container_name: dns-jp
       volumes:
         - ./zone:/etc/bind
       networks:
         anycast-net:
           ipv4_address: 172.20.0.3
     # 模拟一个客户端
     client:
       image: alpine:latest
       container_name: client
       depends_on:
         - dns-server-us
         - dns-server-jp
       networks:
         anycast-net:
           ipv4_address: 172.20.0.10
       command: >
         sh -c "apk add --no-cache bind-tools &&
                echo 'Client is ready. nslookup will be run in 10s...' &&
                sleep 10 &&
                echo 'Querying US server (should resolve to us.example.com):' &&
                nslookup 203.0.113.10 &&
                echo 'Querying JP server (should resolve to jp.example.com):' &&
                nslookup 203.0.113.20"
     # 模拟 BGP 路由器，用于宣告路由
     bgp-router:
       image: ghcr.io/ipspace/exabgp:latest
       container_name: bgp-router
       volumes:
         - ./exabgp.conf:/etc/exabgp/exabgp.conf
       networks:
         anycast-net:
           ipv4_address: 172.20.0.1
       command: exabgp /etc/exabgp/exabgp.conf
   networks:
     anycast-net:
       driver: bridge
       ipam:
         config:
           - subnet: 172.20.0.0/24

2. 创建 DNS 区域文件

   创建 zone 目录和 db.us、db.jp 文件：

   mkdir zone

   zone/db.us (美国服务器区域文件):

   $TTL    86400
   @       IN      SOA     ns1.us.example.com. admin.us.example.com. (
                             2025050101 ; Serial
                             3600       ; Refresh
                             1800       ; Retry
                             604800     ; Expire
                             86400 )    ; Minimum TTL
   ;
   @       IN      NS      ns1.us.example.com.
   ns1     IN      A       172.20.0.2
   ; Anycast IP for US
   10      IN      A       203.0.113.10

   zone/db.jp (日本服务器区域文件):

   $TTL    86400
   @       IN      SOA     ns1.jp.example.com. admin.jp.example.com. (
                             2025050101 ; Serial
                             3600       ; Refresh
                             1800       ; Retry
                             604800     ; Expire
                             86400 )    ; Minimum TTL
   ;
   @       IN      NS      ns1.jp.example.com.
   ns1     IN      A       172.20.0.3
   ; Anycast IP for JP
   20      IN      A       203.0.113.20

3. 创建 ExaBGP 配置文件

   exabgp.conf:

   neighbor 172.20.0.10 {
     router-id 172.20.0.1;
     local-address 172.20.0.1;
     local-as 65001;
     peer-as 65002;
     static {
         route 203.0.113.10/32 next-hop 172.20.0.2;
         route 203.0.113.20/32 next-hop 172.20.0.3;
     }
   }

   • 这个配置告诉 BGP 路由器（客户端），到达 0.113.10/32 的下一跳是 20.0.2（美国服务器），到达 0.113.20/32 的下一跳是 20.0.3（日本服务器）。

4. 启动并观察

   在 anycast-demo 目录下运行：

   docker-compose up --build

   你会看到各个容器启动，重点观察 client 容器的日志输出：

   # 在另一个终端进入 client 容器查看实时日志
   docker logs -f client

   你会看到类似下面的输出：

   Client is ready. nslookup will be run in 10s...
   Querying US server (should resolve to us.example.com):
   Server         172.20.0.2
   Address        172.20.0.2#53
   Name:  10.113.203.in-addr.arpa
   Address: 172.20.0.2  <-- 响应来自美国服务器
   Querying JP server (should resolve to jp.example.com):
   Server         172.20.0.3
   Address        172.20.0.3#53
   Name:  20.113.203.in-addr.arpa
   Address: 172.20.0.3  <-- 响应来自日本服务器

   实验解读：

   • 我们模拟了两个不同的 Anycast IP (0.113.10 和 0.113.20)。
   • BGP 路由器向客户端宣告了去往这两个 IP 的路由,并指定了不同的下一跳。
   • 当客户端查询 0.113.10 时，根据 BGP 路由，它直接请求了 20.0.2（美国服务器）,并得到了正确的响应。
   • 当查询 0.113.20 时，它直接请求了 20.0.3（日本服务器）。
   • 这个实验虽然简化了（没有真正的互联网路由），但它清晰地展示了 BGP 路由如何将 IP 地址映射到物理位置，这是 Anycast 的核心机制。

Anycast 是一种强大而优雅的网络架构，通过利用 BGP 协议，将服务部署在全球多个节点，并让用户自动连接到“最佳”的节点，它极大地提升了服务的可用性、性能和抗攻击能力，是现代 CDN、公共 DNS 和大型云服务不可或缺的基础技术。

虽然它的配置和管理有一定门槛，但其带来的好处使其在构建全球化、高可靠性的服务时，成为了一个极具吸引力的选择，希望这篇教程能帮助你全面理解 Anycast！