CDN 与 WAF 精讲教程 / 第03章 CDN 架构设计
第03章 CDN 架构设计
本章从架构视角深入 CDN 的网络分层设计，涵盖 L4/L7 代理分层、全局负载均衡（GLB）、Anycast 路由等核心技术。
3.1 CDN 总体架构
3.1.1 分层架构概览
┌────────────────────────────────────────────────────────────────────┐
│ CDN 总体架构 │
│ │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ Layer 1: DNS 调度层 (Global Traffic Manager) │ │
│ │ ├── GeoDNS ├── ECS ├── Anycast ├── 健康检查 │ │
│ └──────────────────────────────┬───────────────────────────────┘ │
│ │ │
│ ┌──────────────────────────────▼───────────────────────────────┐ │
│ │ Layer 2: 边缘接入层 (Edge / L4 Load Balancer) │ │
│ │ ├── TCP/UDP 终止 ├── TLS 卸载 ├── DDoS 防护 │ │
│ └──────────────────────────────┬───────────────────────────────┘ │
│ │ │
│ ┌──────────────────────────────▼───────────────────────────────┐ │
│ │ Layer 3: 业务处理层 (L7 Proxy / Application) │ │
│ │ ├── WAF ├── 缓存 ├── 压缩 ├── 路由 ├── 边缘计算 │ │
│ └──────────────────────────────┬───────────────────────────────┘ │
│ │ │
│ ┌──────────────────────────────▼───────────────────────────────┐ │
│ │ Layer 4: 中间层 (Shield / Mid-Tier) │ │
│ │ ├── 二级缓存 ├── 回源合并 ├── 区域路由 │ │
│ └──────────────────────────────┬───────────────────────────────┘ │
│ │ │
│ ┌──────────────────────────────▼───────────────────────────────┐ │
│ │ Layer 5: 源站接入层 (Origin) │ │
│ │ ├── LB ├── App Server ├── DB ├── Object Storage │ │
│ └──────────────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────────┘
3.2 Layer 4 处理
3.2.1 L4 的职责
Layer 4（传输层）处理 TCP/UDP 连接，主要负责：
| 功能 | 说明 | 典型实现 |
|---|
| 连接终止 | 终结客户端 TCP 连接 | LVS / DPVS / iptables |
| TLS 卸载 | 终结 SSL/TLS 握手 | Nginx / HAProxy / 硬件加速卡 |
| L4 负载均衡 | 基于 IP + 端口分发流量 | LVS DR/TUN 模式 |
| DDoS 防护 | SYN Flood、UDP Flood 清洗 | XDP / eBPF / 专用设备 |
| 连接复用 | 多个客户端连接复用到后端 | Nginx upstream keepalive |
3.2.2 L4 负载均衡模式
模式1: DR (Direct Routing) 模式2: TUN (Tunneling)
┌──────┐ ┌─────────┐ ┌──────┐ ┌─────────┐
│Client│──→│ LVS │──→ │Client│──→│ LVS │
└──────┘ │ (VIP) │ ┌──────┐ └──────┘ │ (VIP) │
└────┬────┘ │ RS-1 │(直接回) └────┬────┘
│ └──────┘ │ IPIP隧道
│ ┌──────┐ ▼
└──────→│ RS-2 │ ┌──────┐
└──────┘ │ RS-1 │(隧道回)
└──────┘
模式3: NAT
┌──────┐ ┌─────────┐ ┌──────┐
│Client│──→│ LVS │──→│ RS-1 │──→ 回包经 LVS
└──────┘ │ (VIP) │ └──────┘
└─────────┘ ┌──────┐
│ RS-2 │──→ 回包经 LVS
└──────┘
| 模式 | 性能 | 瓶颈 | 适用场景 |
|---|
| DR | 最高 | RS 需配置 VIP | 大规模 CDN 边缘 |
| TUN | 高 | IP 封装开销 | 跨机房部署 |
| NAT | 中等 | LVS 是回包瓶颈 | 小规模 / 云环境 |
3.2.3 现代 L4 方案
| 技术 | 特点 | 采用者 |
|---|
| DPVS | 基于 DPDK 的高性能 LVS | 百度、爱奇艺 |
| XDP/eBPF | 内核态高速包处理 | Cloudflare |
| Katran | Facebook 开源 L4 LB | Meta/Facebook |
| Maglev | Google 一致性哈希 L4 LB | Google Cloud |
3.3 Layer 7 处理
3.3.1 L7 的职责
Layer 7（应用层）是 CDN 的核心处理层，所有 HTTP 层面的优化和安全都在此完成：
| 功能 | 说明 | 组件 |
|---|
| HTTP 解析 | 解析请求头、Cookie、查询参数 | Nginx / Envoy / Haproxy |
| WAF 过滤 | 应用层安全规则匹配 | ModSecurity / 自研引擎 |
| 缓存代理 | 缓存查找、回源、存储 | Varnish / Traffic Server |
| 内容压缩 | Brotli / Gzip 压缩 | Nginx brotli 模块 |
| URL 重写 | 规则引擎路由请求 | Nginx rewrite / HAProxy ACL |
| 边缘计算 | 在边缘执行用户逻辑 | Workers / Edge Functions |
| 协议升级 | HTTP/1.1 → HTTP/2 / HTTP/3 | Nginx / Envoy |
3.3.2 L7 请求处理流水线
客户端请求
│
▼
┌───────────────────┐
│ 1. 请求解析 │ 解析 HTTP 头、URL、Cookie
└────────┬──────────┘
▼
┌───────────────────┐
│ 2. Bot 检测 │ UA / 行为分析 / 指纹识别
└────────┬──────────┘
▼
┌───────────────────┐
│ 3. WAF 规则匹配 │ SQL 注入 / XSS / RCE 检测
└────────┬──────────┘
▼
┌───────────────────┐
│ 4. Rate Limiting │ 频率限制、CC 防护
└────────┬──────────┘
▼
┌───────────────────┐
│ 5. 路由决策 │ URL 路由、A/B 测试、灰度
└────────┬──────────┘
▼
┌───────────────────┐
│ 6. 缓存查找 │ HIT → 直接响应（跳到步骤 9）
└────────┬──────────┘
│ MISS
▼
┌───────────────────┐
│ 7. 回源 │ Shield → Origin
└────────┬──────────┘
▼
┌───────────────────┐
│ 8. 响应处理 │ 缓存存储 + 响应头修改
└────────┬──────────┘
▼
┌───────────────────┐
│ 9. 内容压缩 │ Brotli / Gzip
└────────┬──────────┘
▼
┌───────────────────┐
│ 10. 响应返回 │ TLS 加密 → 发送给客户端
└───────────────────┘
3.4 全局负载均衡（GLB）
3.4.1 GLB 概念
GLB（Global Load Balancing，全局负载均衡） 是 CDN 的"大脑"，决定每个用户请求由哪个 PoP 处理。与单机房的 L4/L7 负载均衡不同，GLB 工作在 DNS 层面，跨越全球数据中心。
3.4.2 GLB 调度维度
| 维度 | 说明 | 权重 |
|---|
| 地理位置 | 用户到 PoP 的物理距离 | 高 |
| 网络延迟 | 实时探测的 RTT 值 | 高 |
| 节点负载 | CPU、内存、带宽使用率 | 中 |
| 节点健康 | 健康检查通过/失败 | 最高（故障排除） |
| 成本 | 不同区域带宽成本差异 | 低 |
| 用户归属 | 运营商、企业专属节点 | 按需 |
3.4.3 GLB 架构示例
┌──────────────────────────┐
│ GLB 调度系统 │
│ ┌─────────────────────┐ │
│ │ 实时数据采集 │ │
│ │ ├── 节点健康状态 │ │
│ │ ├── 网络延迟探测 │ │
│ │ ├── 节点负载指标 │ │
│ │ └── 流量预测模型 │ │
│ └──────────┬──────────┘ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ 调度决策引擎 │ │
│ │ ├── Geo → 候选 PoP │ │
│ │ ├── 延迟排序 │ │
│ │ ├── 负载过滤 │ │
│ │ └── 故障剔除 │ │
│ └──────────┬──────────┘ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ DNS 响应生成 │ │
│ │ 返回最优 PoP 的 IP │ │
│ └─────────────────────┘ │
└──────────────────────────┘
3.4.4 调度策略对比
| 策略 | 适用场景 | 优点 | 缺点 |
|---|
| 静态 Geo | 一般网站 | 简单可靠 | 不感知实时网络变化 |
| 动态探测 | 低延迟要求业务 | 最优路由 | 系统复杂 |
| 加权轮询 | 多活容灾 | 均匀分布 | 不感知距离 |
| 故障转移 | 高可用架构 | 快速切换 | 需健康检查 |
3.5 Anycast 路由
3.5.1 Anycast 原理
Anycast（任播） 是一种网络寻址方式，多个节点共享同一个 IP 地址，BGP 路由协议自动将用户请求导向最近的节点。
Anycast vs Unicast vs Multicast：
Unicast（单播）：1 IP → 1 节点
Client ──→ [节点A] 10.0.0.1
Anycast（任播）：1 IP → 多节点（最近者响应）
Client(北京) ──→ [节点A 北京] 10.0.0.1 ← BGP 选最近
Client(上海) ──→ [节点B 上海] 10.0.0.1 ← 同一 IP
Client(广州) ──→ [节点C 广州] 10.0.0.1 ← 不同物理机
Multicast（组播）：1 IP → 多节点同时接收
Client ──→ [节点A, 节点B, 节点C] 224.0.0.1
3.5.2 Anycast 在 CDN 中的应用
| 厂商 | Anycast 用途 | 说明 |
|---|
| Cloudflare | 全部流量 | 所有边缘节点共享 Anycast IP |
| Google Cloud CDN | 边缘接入 | 基于 Google 全球骨干网 |
| Fastly | 边缘接入 | 多 Anycast 集群 |
| AWS | 边缘接入 | 部分 Anycast |
3.5.3 Anycast 优缺点
| 优点 | 缺点 |
|---|
| 天然就近访问，无需 DNS 精确调度 | BGP 收敛慢（故障切换可能需数分钟） |
| 天然 DDoS 分散（攻击流量分散到全球） | TCP 会话迁移困难 |
| 配置简单（同一 IP） | 路由不对称问题 |
| 与 BGP 健康检查结合可实现自动故障转移 | 调试困难 |
3.5.4 Anycast + Unicast 混合架构
大型 CDN 混合架构：
┌──────────────────────────────────────────────────────────┐
│ Anycast 层 │
│ ├── DDoS 流量清洗入口 │
│ ├── DNS 权威服务器 │
│ └── 初步流量分发 │
└───────────────────────┬──────────────────────────────────┘
│
┌───────────────────────▼──────────────────────────────────┐
│ Unicast 层 │
│ ├── 各区域 PoP 使用独立 Unicast IP │
│ ├── GLB 精确调度到具体 PoP │
│ └── 支持精细化流量管理 │
└──────────────────────────────────────────────────────────┘
3.6 高可用设计
3.6.1 故障域隔离
故障域层级：
┌────────────────────────────────────────────────┐
│ Region (区域) │
│ ├── Availability Zone (可用区) │
│ │ ├── Cluster (集群) │
│ │ │ ├── Node (节点) │
│ │ │ └── Node (节点) │
│ │ └── Cluster (集群) │
│ └── Availability Zone (可用区) │
└────────────────────────────────────────────────┘
设计原则：
- 同一 PoP 跨至少 2 个可用区
- 同一区域有至少 2 个 PoP
- 关键服务 N+2 冗余
3.6.2 健康检查机制
| 层级 | 检查方式 | 频率 | 故障响应 |
|---|
| L4 | TCP 连接探测 | 1-5s | 标记节点不可用 |
| L7 | HTTP 200 检查 | 5-10s | 从负载均衡池移除 |
| 业务 | 自定义健康接口 | 10-30s | 配合 GLB 调度 |
| 全局 | 综合评分 | 30-60s | DNS 权重调整 |
3.7 注意事项
⚠️ TLS 版本：CDN 边缘应仅支持 TLS 1.2+，禁用 SSLv3、TLS 1.0/1.1。
⚠️ 连接复用率：保持源站连接池高复用率（Keep-Alive），减少 TCP/TLS 握手开销。
⚠️ SNI 一致性：确保 L4 层正确传递 SNI（Server Name Indication），否则多域名 HTTPS 会失败。
3.8 扩展阅读
本章小结
| 主题 | 核心要点 |
|---|
| L4 处理 | TCP 终止、TLS 卸载、DDoS 初步防护 |
| L7 处理 | HTTP 解析、WAF、缓存、压缩的核心层 |
| GLB | 全球调度系统，综合地理位置、延迟、负载决策 |
| Anycast | 多节点共享 IP，BGP 路由实现天然就近 |
| 高可用 | 故障域隔离 + 健康检查 + N+2 冗余 |
下一章：第04章 缓存策略 →