【网络工程】CDN 架构原理：PoP、边缘节点与 Origin Shield

CDN（Content Delivery Network）的概念很简单——把内容放到离用户近的地方。但当你深入工程细节，会发现”简单”背后隐藏着大量架构决策：

• 用户的请求是怎么被导向最近的边缘节点的？
• 边缘节点没有缓存时，回源请求怎么组织才不会压垮源站？
• Origin Shield 到底解决了什么问题？
• 多 CDN 部署怎么做到无缝切换？

这些问题的答案构成了 CDN 架构的核心。本文从 DNS 调度链路、PoP 内部结构、Origin Shield 机制到多 CDN 架构，系统解剖 CDN 的工程原理。

一、CDN 的调度链路

用户输入 URL 后，CDN 如何把请求导向最优边缘节点？核心靠 DNS。

1.1 DNS 调度流程

用户浏览器请求 www.example.com：

1. 浏览器 → Local DNS Resolver
   "www.example.com 的 IP 是什么？"

2. Local DNS → 权威 DNS（example.com）
   返回 CNAME: www.example.com → www.example.com.cdn.provider.net

3. Local DNS → CDN 权威 DNS（cdn.provider.net）
   CDN DNS 根据以下信息决定返回哪个边缘节点 IP：
   ├── 用户的 Local DNS IP（地理位置推断）
   ├── EDNS Client Subnet（更精确的用户 IP 段）
   ├── 各 PoP 的健康状态和负载
   ├── 实时网络质量数据
   └── 预设的流量调度策略

4. CDN DNS → Local DNS → 浏览器
   返回最优边缘节点 IP: 203.0.113.10

5. 浏览器 → 边缘节点 203.0.113.10
   发送 HTTP 请求

1.2 CNAME 链与 DNS 配置

CDN 接入通常通过 CNAME 实现：

# 查看 CDN 的 DNS 解析链路
dig +trace www.example.com

# 典型输出：
# www.example.com.       300  IN  CNAME  www.example.com.cdn77.org.
# www.example.com.cdn77.org. 60 IN CNAME cdn77-a.example.cdn77.org.
# cdn77-a.example.cdn77.org. 30 IN A     203.0.113.10

# DNS 配置（域名注册商处）
# www  CNAME  www.example.com.cdn.provider.net.

CNAME 的限制：

根域名（example.com）不能设 CNAME（RFC 1034 限制）

解决方案：
1. ALIAS / ANAME 记录（部分 DNS 提供商支持）
   example.com  ALIAS  example.com.cdn.provider.net

2. Cloudflare 的 CNAME Flattening
   自动在权威 DNS 层面解析 CNAME 并返回 A 记录

3. 使用 A 记录直接指向 CDN 提供的 Anycast IP
   example.com  A  203.0.113.10（CDN Anycast）

1.3 EDNS Client Subnet

传统 DNS 调度基于 Local DNS Resolver 的 IP 推断用户位置，但用户可能使用远离自己的公共 DNS（如 Google 8.8.8.8）。EDNS Client Subnet（ECS，RFC 7871）解决这个问题：

无 ECS：
用户（上海）→ Google DNS（美国）→ CDN DNS
CDN DNS 看到 Google DNS IP → 返回美国边缘节点
用户跨洋访问 → 延迟高

有 ECS：
用户（上海）→ Google DNS（美国）→ CDN DNS
DNS 查询包含：EDNS Client Subnet: 116.228.0.0/16（用户 IP 段）
CDN DNS 看到用户在上海 → 返回上海边缘节点
用户就近访问 → 延迟低

验证 ECS 支持：

# 查询时携带 ECS
dig @8.8.8.8 www.example.com +subnet=116.228.0.0/24

# 对比不同 ECS 的解析结果
dig @8.8.8.8 www.example.com +subnet=116.228.0.0/24  # 上海
dig @8.8.8.8 www.example.com +subnet=1.1.1.0/24      # 北美

# 如果返回不同 IP → CDN 支持 ECS 调度

1.4 Anycast 调度

除了 DNS 调度，部分 CDN（Cloudflare、Fastly）使用 Anycast（任播）：

Anycast 模式：
- CDN 在全球所有 PoP 宣告同一个 IP 地址
- 用户的请求被 BGP 路由到最近的 PoP
- 无需 DNS 层面的智能调度

优点：
- 调度精度高（基于真实网络路径而非 DNS IP）
- DNS TTL 不影响切换速度
- 对 DDoS 天然抗性（攻击流量分散到全球）

缺点：
- 需要自己运营 AS（自治系统）
- BGP 收敛时间影响故障切换速度（30-120 秒）
- 不支持按用户地理的精细化调度

1.5 DNS 调度 vs Anycast 对比

二、PoP 内部架构

PoP（Point of Presence）是 CDN 在一个地理位置的服务器集群。PoP 的内部架构决定了缓存效率和回源行为。

2.1 典型 PoP 结构

一个 CDN PoP 的内部架构：

互联网流量
    │
    ▼
┌─────────────────────────────────┐
│          Router / L4 LB         │  ← BGP 宣告，ECMP 分流
├─────────────────────────────────┤
│     Edge Server 1    Edge 2     │  ← TLS 终止 + HTTP 缓存
│     Edge Server 3    Edge 4     │  ← 处理用户请求
├─────────────────────────────────┤
│        Mid-tier Cache           │  ← 二级缓存（可选）
├─────────────────────────────────┤
│        Origin Shield            │  ← 回源保护（可选）
└──────────────┬──────────────────┘
               │
               ▼
          源站（Origin）

2.2 Edge Server 的角色

Edge Server 是用户请求的直接处理者。它的工作流程：

请求到达 Edge Server：

1. TLS 终止
   - 解密 HTTPS 请求
   - 使用会话复用减少握手开销

2. HTTP 解析
   - 解析 Host、Path、Query String、Headers
   - 计算 Cache Key

3. 缓存查找
   - 查找本地缓存（内存 → SSD → HDD）
   ├── HIT  → 直接返回缓存内容
   ├── MISS → 向上一级请求（Mid-tier 或 Origin）
   └── STALE → 返回旧内容 + 后台异步回源刷新

4. 回源（如果 MISS）
   - 向 Mid-tier Cache 或 Origin Shield 请求
   - 接收响应后缓存并返回给用户
   - 缓存控制遵循 Cache-Control / s-maxage

5. 响应发送
   - 添加 CDN 特有头（X-Cache、Age、Via 等）
   - 压缩（如果需要）
   - 发送给用户

2.3 Cache Key 设计

Cache Key 决定了”什么算同一个资源”。Cache Key 设计不当会导致缓存命中率低或返回错误内容：

默认 Cache Key（大多数 CDN）：
  Scheme + Host + Path + Query String

示例：
  https://www.example.com/api/data?page=1&sort=name
  https://www.example.com/api/data?sort=name&page=1
  → 不同的 Cache Key！（Query String 顺序不同）

Nginx 缓存 Key 配置：

# 自定义 Cache Key
proxy_cache_key "$scheme$host$request_uri";

# 忽略 Query String（静态资源）
location ~* \.(css|js|png|jpg|gif|ico|woff2)$ {
    proxy_cache_key "$scheme$host$uri";  # 不含 $args
    proxy_cache static_cache;
    proxy_cache_valid 200 30d;
}

# 包含特定 Query 参数
# 需要用 Lua 或 map 过滤
map $args $cache_args {
    ~page=(?<p>[^&]+)     "page=$p";
    ~id=(?<i>[^&]+)       "id=$i";
    default               "";
}
proxy_cache_key "$scheme$host$uri$cache_args";

Cache Key 的常见配置：

Cache Key 组成元素：
├── Scheme（http vs https）
│   通常忽略 → 统一用 https
├── Host
│   必须包含
├── Path
│   必须包含
├── Query String
│   ├── 全部包含（默认）
│   ├── 忽略全部（静态资源推荐）
│   ├── 只包含特定参数
│   └── 排序后包含（避免顺序影响）
├── Cookie
│   通常不包含（否则每个用户一份缓存）
│   特殊场景：A/B 测试 Cookie
├── Header
│   Accept-Encoding → 区分 gzip/br/identity
│   Accept-Language → 多语言站点
└── 自定义
    设备类型（mobile/desktop）
    地理位置（国家/地区）

Cloudflare Workers 自定义 Cache Key：

// Cloudflare Workers 自定义 Cache Key
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const url = new URL(request.url)
  
  // 自定义 Cache Key：忽略营销参数
  const cacheUrl = new URL(url)
  cacheUrl.searchParams.delete('utm_source')
  cacheUrl.searchParams.delete('utm_medium')
  cacheUrl.searchParams.delete('utm_campaign')
  cacheUrl.searchParams.delete('fbclid')
  
  // 排序 Query String
  cacheUrl.searchParams.sort()
  
  const cacheKey = new Request(cacheUrl.toString(), request)
  
  const cache = caches.default
  let response = await cache.match(cacheKey)
  
  if (!response) {
    response = await fetch(request)
    // 只缓存成功响应
    if (response.ok) {
      const clonedResponse = response.clone()
      event.waitUntil(cache.put(cacheKey, clonedResponse))
    }
  }
  
  return response
}

2.4 多级缓存

大型 CDN 通常有多级缓存，减少回源量：

用户请求的缓存查找路径：

L1: Edge Server 本地缓存（内存 + SSD）
    ├── HIT → 返回
    └── MISS ↓

L2: PoP 内共享缓存（Mid-tier）
    ├── HIT → 返回 + 回填 L1
    └── MISS ↓

L3: Origin Shield（独立 PoP 或专用层）
    ├── HIT → 返回 + 回填 L2、L1
    └── MISS ↓

L4: 源站（Origin）
    返回 → 逐级回填 L3、L2、L1

一致性哈希与缓存分片：

大型 PoP 的 Edge Server 之间通常使用一致性哈希来分配缓存内容，避免同一资源在多台 Edge 上重复缓存：

PoP 内有 8 台 Edge Server：

无一致性哈希：
  /image.jpg 可能缓存在所有 8 台 → 浪费 7 份存储

有一致性哈希：
  hash("/image.jpg") → Edge-3
  所有对 /image.jpg 的请求都路由到 Edge-3
  → 存储效率 8 倍提升
  → 但单台 Edge 故障影响其上所有内容

Varnish 的 Director 模块实现缓存分片：
  sub vcl_init {
      new cluster = directors.hash();
      cluster.add_backend(edge1, 1);
      cluster.add_backend(edge2, 1);
      cluster.add_backend(edge3, 1);
  }
  sub vcl_recv {
      set req.backend_hint = cluster.backend(req.url);
  }

每一级的缓存特征：

三、Origin Shield

Origin Shield 是 CDN 架构中减少回源压力的关键机制。它在所有边缘节点和源站之间增加一个中间缓存层。

3.1 为什么需要 Origin Shield

没有 Origin Shield 时的问题：

场景：CDN 有 100 个 PoP，一个资源的 TTL 过期

无 Origin Shield：
PoP-1  ──回源──→ Origin
PoP-2  ──回源──→ Origin
PoP-3  ──回源──→ Origin
...
PoP-100 ──回源──→ Origin
→ 同一资源同时收到 100 个回源请求！

有 Origin Shield：
PoP-1  ──→ Origin Shield ──1次回源──→ Origin
PoP-2  ──→ Origin Shield（缓存命中）
PoP-3  ──→ Origin Shield（缓存命中）
...
PoP-100 ──→ Origin Shield（缓存命中）
→ 源站只收到 1 个请求

3.2 Origin Shield 的工程实现

Origin Shield 通常是一个或多个专用 PoP，所有边缘节点的回源请求都汇聚到这里：

Origin Shield 选择策略：
1. 选择离源站最近的 PoP 作为 Origin Shield
   → 最小化 Shield 到 Origin 的延迟
   
2. 选择多个 Shield PoP 做冗余
   → Shield-East + Shield-West
   → 边缘节点根据地理位置选择最近的 Shield

3. 按域名分配不同的 Shield
   → static.example.com → Shield-A
   → api.example.com → Shield-B

AWS CloudFront Origin Shield 配置：

{
  "Origins": {
    "Items": [
      {
        "Id": "myOrigin",
        "DomainName": "origin.example.com",
        "OriginShield": {
          "Enabled": true,
          "OriginShieldRegion": "us-east-1"
        }
      }
    ]
  }
}

Cloudflare Tiered Cache（等价于 Origin Shield）：

Cloudflare 的 Tiered Cache 拓扑：
├── Tier 1: 所有边缘 PoP（~300 个城市）
├── Tier 2: 区域中心 PoP（~30 个）
└── Tier 3: 超级 PoP（~10 个）→ 回源

3.3 Origin Shield 的代价

Origin Shield 不是免费的：

3.4 回源合并（Request Collapsing）

Origin Shield 之外，另一个减少回源的机制是请求合并——当多个用户同时请求同一个未缓存资源时，只向源站发一个请求：

请求合并示例：

T=0ms: 用户 A 请求 /image.jpg → Cache MISS → 发起回源请求
T=5ms: 用户 B 请求 /image.jpg → Cache MISS → 等待（不发新请求）
T=10ms: 用户 C 请求 /image.jpg → Cache MISS → 等待
T=50ms: 源站响应到达 → 同时返回给用户 A、B、C

Nginx 的请求合并配置：

# proxy_cache_lock 实现请求合并
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=cache:10m;

location / {
    proxy_cache cache;
    proxy_cache_lock on;            # 启用请求合并
    proxy_cache_lock_age 5s;        # 最长等待时间
    proxy_cache_lock_timeout 5s;    # 超时后直接回源
    
    # stale-while-revalidate：返回旧缓存的同时后台刷新
    proxy_cache_use_stale updating;
}

四、回源策略

边缘节点到源站的请求行为对性能和可靠性至关重要。

4.1 回源行为控制

回源策略的两种模式：

Follow Origin（跟随源站）：
- CDN 完全遵循源站的 Cache-Control 头
- 源站说 max-age=3600 → CDN 缓存 3600 秒
- 源站说 no-cache → CDN 不缓存

Override（覆盖源站）：
- CDN 忽略源站的 Cache-Control，使用 CDN 侧配置
- 适用于源站 Cache-Control 设置不合理的场景
- 例如：源站所有响应都是 no-cache，但静态资源应该被缓存

CDN 控制面板的典型配置（以 Cloudflare 为例）：

Browser Cache TTL: Respect Existing Headers
  → 浏览器缓存时间由源站控制

Edge Cache TTL: 
  → 覆盖源站的 s-maxage / max-age
  → 设为 7200 表示边缘缓存 2 小时

Page Rules（精细控制）:
  *.example.com/static/*  → Cache Level: Cache Everything, Edge TTL: 30d
  api.example.com/*       → Cache Level: Bypass
  *.example.com/*.html    → Cache Level: Standard, Edge TTL: 1h

4.2 回源协议与连接

# Nginx 作为 CDN 边缘节点的回源配置
upstream origin {
    server origin.example.com:443;
    
    # 回源连接池
    keepalive 32;
    keepalive_requests 1000;
    keepalive_timeout 60s;
}

server {
    location / {
        proxy_pass https://origin;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        
        # 回源 Host 头（必须正确设置）
        proxy_set_header Host $host;
        
        # 回源超时
        proxy_connect_timeout 5s;
        proxy_read_timeout 30s;
        
        # 回源失败重试
        proxy_next_upstream error timeout http_502 http_503;
        proxy_next_upstream_tries 2;
        proxy_next_upstream_timeout 10s;
        
        # 传递用户信息
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

4.3 回源鉴权

防止非 CDN 节点直接访问源站：

# 方案一：共享密钥（Origin Header 验证）
# CDN 配置添加自定义头
# X-Origin-Token: secret-token-12345

# 源站 Nginx 验证
# server {
#     if ($http_x_origin_token != "secret-token-12345") {
#         return 403;
#     }
# }

# 方案二：IP 白名单
# 只允许 CDN 的回源 IP 访问源站
# iptables -A INPUT -p tcp --dport 443 -s CDN_IP_RANGE -j ACCEPT
# iptables -A INPUT -p tcp --dport 443 -j DROP

# 方案三：mTLS（双向 TLS）
# CDN 使用客户端证书连接源站
# 源站验证 CDN 的证书

4.4 故障回源策略

CDN 回源失败时的处理策略：

1. 返回错误页面
   → 自定义 502/503 错误页
   → 显示"服务暂时不可用"

2. 返回 Stale 内容
   → 如果有过期缓存，返回旧内容
   → 配合 stale-if-error 使用

3. 切换到备用源站
   → 主源站不可用时切换到备用
   → 需要 CDN 支持多源站配置

4. 重试其他 PoP
   → 如果是 PoP 到源站的网络问题
   → 尝试从其他 PoP 回源

# stale-if-error 配置
proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504;

# 自定义错误页面
error_page 502 503 504 /custom_error.html;
location = /custom_error.html {
    internal;
    root /var/www/error;
}

五、多 CDN 架构

大型站点通常使用多个 CDN 提供商，以提高可用性和性能。

5.1 多 CDN 的动机

为什么用多 CDN：
1. 可用性：一个 CDN 故障时自动切换
2. 性能：不同地区选择最优 CDN
3. 成本：利用不同 CDN 的价格优势
4. 议价能力：避免被单一供应商锁定

5.2 多 CDN 调度方案

方案一：DNS 层调度

# 使用 DNS 负载均衡在多 CDN 间分流
# Route 53 加权路由
www.example.com  CNAME  www.example.com.cdn-a.net  (weight: 70)
www.example.com  CNAME  www.example.com.cdn-b.net  (weight: 30)

# 或使用延迟路由
# Route 53 根据用户位置选择延迟最低的 CDN

方案二：专用 GSLB 服务

专用 CDN 调度服务（Cedexis / Citrix ITM / NS1）：

用户 → GSLB 服务 → 实时测量各 CDN 性能 → 选择最优 CDN

GSLB 的决策依据：
├── 实时延迟测量（RUM / Synthetic）
├── CDN 可用性状态
├── 各 CDN 的流量成本
├── 地理/运营商匹配
└── 自定义业务规则

方案三：边缘决策（Cloudflare Workers / AWS Lambda@Edge）

// 在一个 CDN 的边缘决策是否回源到另一个 CDN
async function handleRequest(request) {
  const primaryResponse = await fetch(request.url, {
    cf: { timeout: 3000 }
  })
  
  if (!primaryResponse.ok) {
    // 主 CDN 失败，fallback 到备用 CDN
    const backupUrl = request.url.replace(
      'cdn-primary.example.com',
      'cdn-backup.example.com'
    )
    return fetch(backupUrl)
  }
  
  return primaryResponse
}

5.3 多 CDN 的挑战

多 CDN 部署的工程挑战：

1. 缓存一致性
   - 资源更新后需要 Purge 所有 CDN
   - 不同 CDN 的 Purge API 不同
   - Purge 传播时间不同

2. SSL 证书管理
   - 每个 CDN 都需要配置证书
   - 证书续期需要同步到所有 CDN
   - 部分 CDN 要求上传私钥

3. 配置同步
   - 缓存规则、安全策略需要在所有 CDN 同步
   - 不同 CDN 的配置语法和能力不同
   - 保持配置一致性是持续的运维负担

4. 监控统一
   - 需要聚合多个 CDN 的监控数据
   - 日志格式不统一
   - 告警需要考虑整体可用性

六、CDN 响应头分析

理解 CDN 的响应头是诊断缓存行为的关键技能。

6.1 常见 CDN 响应头

# 请求一个通过 CDN 分发的资源
curl -sI https://www.example.com/static/app.js

# 典型 CDN 响应头：
HTTP/2 200
content-type: application/javascript
content-length: 45230
cache-control: public, max-age=31536000
age: 3600
x-cache: Hit from cloudfront
x-amz-cf-pop: IAD89-P2
x-amz-cf-id: abc123==
via: 1.1 a1b2c3.cloudfront.net (CloudFront)

各头的含义：

6.2 各 CDN 的缓存状态标识

# CloudFront
X-Cache: Hit from cloudfront     # 缓存命中
X-Cache: Miss from cloudfront    # 缓存未命中，回源
X-Cache: RefreshHit from cloudfront  # 过期内容刷新成功

# Cloudflare
CF-Cache-Status: HIT             # 缓存命中
CF-Cache-Status: MISS            # 未命中，回源
CF-Cache-Status: EXPIRED         # 过期，重新验证
CF-Cache-Status: STALE           # 返回过期内容
CF-Cache-Status: DYNAMIC         # 不可缓存（动态内容）
CF-Cache-Status: BYPASS          # 被规则跳过

# Fastly
X-Cache: HIT, HIT               # Shield HIT + Edge HIT
X-Cache: MISS, HIT              # Shield MISS + Edge HIT
X-Cache: MISS, MISS             # 全部未命中
X-Cache-Hits: 5                  # 该对象被命中 5 次

# Akamai
X-Cache: TCP_HIT from a1.deploy.akamaitechnologies.com
X-Cache: TCP_MISS from a1.deploy.akamaitechnologies.com

6.3 调试缓存问题的方法

# 1. 检查资源是否被缓存
curl -sI https://www.example.com/static/app.js | grep -i "x-cache\|cf-cache\|age"

# 2. 对比不同 PoP 的缓存状态
# 通过 --resolve 指定不同的边缘节点 IP
curl -sI --resolve www.example.com:443:203.0.113.10 https://www.example.com/app.js | grep x-cache
curl -sI --resolve www.example.com:443:203.0.113.20 https://www.example.com/app.js | grep x-cache

# 3. 检查 Cache-Control 头是否正确
curl -sI https://www.example.com/api/data | grep -i cache-control
# 期望动态 API：no-cache 或 private
# 期望静态资源：public, max-age=31536000

# 4. 检查 Vary 头（影响 Cache Key）
curl -sI https://www.example.com/app.js | grep -i vary
# Vary: Accept-Encoding → 正常
# Vary: * → 不可缓存！
# Vary: Cookie → 每个用户一份缓存（通常是错误配置）

# 5. 强制绕过缓存（直接回源）
curl -sI -H "Cache-Control: no-cache" -H "Pragma: no-cache" \
  https://www.example.com/app.js | grep -i "x-cache\|age"

七、总结

CDN 不是”配好 CNAME 就完事了”——它是一个复杂的分布式缓存系统，需要理解调度机制、缓存层级和回源策略才能用好。

我的工程建议：

1. DNS 调度和 Anycast 不是互斥的。DNS 调度灵活但受 TTL 限制；Anycast 精确但运营成本高。大多数 CDN 结合两者使用。选择 CDN 时，了解其调度机制有助于理解延迟和故障切换行为。

2. Origin Shield 应该是默认开启的。它几乎总是正收益——减少回源请求的收益远大于增加一跳延迟的代价。只有源站本身就在 CDN 网络内（如 Cloudflare Pages）时才不需要。

3. Cache Key 设计是命中率的关键。默认 Cache Key 通常包含完整 Query String，但营销追踪参数（utm_*、fbclid）会严重降低命中率。在 CDN 层面过滤这些参数是高性价比的优化。

4. 理解 CDN 响应头是诊断的基础。X-Cache、Age、CF-Cache-Status 这些头告诉你资源是否被缓存、缓存了多久、在哪个 PoP 服务。线上缓存问题的排查从这些头开始。

5. 多 CDN 的运维成本比你想的高。配置同步、证书管理、缓存 Purge、监控聚合——每一项都是持续的运维负担。除非你有明确的可用性或性能需求，否则一个可靠的 CDN 加上良好的源站架构就够了。

6. stale-while-revalidate 是最被低估的缓存策略。它让 CDN 在缓存过期时返回旧内容（零延迟）的同时后台刷新。对于不需要实时一致性的资源（CSS、JS、图片），这个策略能显著改善用户体验。

上一篇：网关选型对比：Nginx vs HAProxy vs Envoy vs Traefik

下一篇：CDN 缓存策略：TTL、Purge 与 stale-while-revalidate