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章 缓存策略 →