互联网应用的用户遍布全球，从北京到纽约、从东京到伦敦，一次 HTTP 请求如果需要跨越半个地球才能到达源站服务器，延迟可能高达数百毫秒。内容分发网络（Content Delivery Network，简称 CDN）通过在全球各地部署边缘节点，将内容推送到离用户最近的位置，从根本上缩短了用户与内容之间的物理距离。本文将从底层原理到工程实践，系统讲解 CDN 的架构设计。

1.1 什么是 CDN

CDN 是一组分布在全球不同地理位置的服务器集群，它们协同工作，将网站和应用的静态与动态内容缓存并分发给终端用户。其核心目标是降低延迟（Latency）、提升吞吐量（Throughput）、增强可用性（Availability）。

CDN 的诞生源于一个简单的物理事实：光在光纤中的传播速度约为每毫秒 200 公里。从上海到旧金山的直线距离约 9500 公里，仅光传播就需要约 48 毫秒，加上路由跳转、协议握手等开销，实际延迟远高于此。CDN 通过在距离用户更近的位置缓存内容，直接消除了大部分网络传输延迟。

1.2 核心组件

CDN 架构由以下关键组件构成：

接入点（Point of Presence，PoP）：PoP 是 CDN 在某个地理区域的物理部署单元，通常位于互联网交换点（Internet Exchange Point，IXP）或主要数据中心。一个 PoP 内包含多台边缘服务器、负载均衡器和本地 DNS 解析器。全球大型 CDN 提供商通常拥有数百个 PoP 节点。

边缘服务器（Edge Server）：边缘服务器位于 PoP 内部，直接面向终端用户。它们承担内容缓存、TLS 终止、压缩、请求路由等功能。边缘服务器是用户请求的第一个接触点。

区域中间层（Mid-tier / Regional Cache）：部分 CDN 在边缘和源站之间设置区域缓存层。当边缘节点缓存未命中时，请求首先到达区域中间层，而非直接回源。这有效减少了源站的请求压力。

源站护盾（Origin Shield）：源站护盾是部署在源站前方的集中式缓存层，所有回源请求都通过它中转。它将来自全球各地边缘节点的回源请求合并，使源站只需处理极少量的请求。

源站服务器（Origin Server）：源站是内容的最终来源，存储着网站或应用的原始数据。CDN 的一切缓存和分发操作，最终都以源站内容为基准。

1.3 请求流程

当用户访问一个 CDN 加速的网站时，请求经历如下流程：

1. 用户在浏览器中输入域名，发起 DNS 查询
2. DNS 系统通过 CNAME 链将域名解析引导至 CDN 的全局负载均衡系统
3. 全局负载均衡根据用户地理位置、网络状况和节点健康度选择最优 PoP
4. 用户浏览器与选中 PoP 的边缘服务器建立连接
5. 边缘服务器检查本地缓存：若命中则直接返回；若未命中则向上层请求
6. 请求依次经过区域中间层、源站护盾，最终到达源站
7. 源站响应沿原路返回，各层级缓存将内容存储以供后续请求使用

以下是 CDN 请求流程的架构图：

graph LR
    A[用户浏览器] -->|DNS 查询| B[DNS / GSLB]
    B -->|返回最优 PoP IP| A
    A -->|HTTPS 请求| C[边缘服务器<br/>Edge Server]
    C -->|缓存命中| A
    C -->|缓存未命中| D[区域中间层<br/>Mid-tier Cache]
    D -->|缓存命中| C
    D -->|缓存未命中| E[源站护盾<br/>Origin Shield]
    E -->|缓存命中| D
    E -->|缓存未命中| F[源站服务器<br/>Origin Server]
    F -->|响应内容| E
    E -->|缓存并转发| D
    D -->|缓存并转发| C
    C -->|缓存并返回| A

    style A fill:#e1f5fe
    style C fill:#c8e6c9
    style D fill:#fff9c4
    style E fill:#ffe0b2
    style F fill:#ffcdd2

1.4 CDN 的核心价值

CDN 对系统架构的核心价值可以从以下几个维度理解：

性能提升：通过就近服务，将往返时间（Round-Trip Time，RTT）从数百毫秒降至个位数毫秒。对于需要多次 RTT 的 TLS 握手和 TCP 慢启动过程，这种优化效果尤为显著。

源站卸载：CDN 缓存可以承担超过 90% 的请求，源站只需处理极少量的回源请求。这意味着源站可以使用更少的服务器资源。

可用性增强：即使源站发生故障，边缘缓存仍可继续提供已缓存的内容。CDN 的分布式架构本身就具备天然的容灾能力。

安全防护：现代 CDN 提供 DDoS 防护、Web 应用防火墙（WAF）、速率限制等安全功能，将攻击流量拦截在边缘节点。

二、DNS 路由与 Anycast 路由

将用户请求引导至最优边缘节点是 CDN 架构的关键问题。目前业界主要采用两种路由方案：基于 DNS 的路由和基于 Anycast 的路由。

2.1 DNS 路由

DNS 路由是传统 CDN 最常用的用户调度方案。其工作流程如下：

CNAME 链：网站管理员将域名（如 www.example.com）的 DNS 记录配置为一个 CNAME，指向 CDN 提供商的域名（如 www.example.com.cdn.example.net）。CDN 提供商的权威 DNS 服务器接管后续解析过程。

全局服务器负载均衡（Global Server Load Balancing，GSLB）：CDN 的权威 DNS 服务器并非返回固定 IP 地址，而是根据多种因素动态决定响应内容。这些因素包括：

• 用户 DNS 解析器的 IP 地址（用于推测用户地理位置）
• EDNS Client Subnet（ECS）扩展（直接携带用户子网信息）
• 各 PoP 节点的健康状态和当前负载
• 网络探测数据（延迟、丢包率等）

GeoDNS：基于地理位置的 DNS 解析是 GSLB 最常用的实现方式。系统维护一个 IP 地址到地理位置的映射数据库（如 MaxMind GeoIP），根据请求来源返回地理上最近的 PoP 节点 IP。

DNS 路由的核心配置示例：

# 用户域名 DNS 配置
www.example.com.    300  IN  CNAME  www.example.com.cdn.cloudprovider.net.

# CDN 权威 DNS 根据来源返回不同 IP
# 来自亚洲的查询 -> 返回东京 PoP
www.example.com.cdn.cloudprovider.net.  60  IN  A  103.21.244.10
# 来自欧洲的查询 -> 返回法兰克福 PoP
www.example.com.cdn.cloudprovider.net.  60  IN  A  198.41.215.20
# 来自北美的查询 -> 返回阿什本 PoP
www.example.com.cdn.cloudprovider.net.  60  IN  A  172.64.100.30

DNS 路由的优势在于兼容性好、部署灵活，但也存在固有缺陷：DNS 解析存在缓存，TTL 过期前用户可能继续访问已不可用的节点；此外，用户使用的递归 DNS 解析器（如 8.8.8.8）位置可能与用户实际位置不一致，导致调度偏差。

2.2 Anycast 路由

Anycast 是一种网络寻址和路由方法：同一个 IP 地址被分配给多个地理位置的服务器，网络层通过 BGP（Border Gateway Protocol）路由协议自动将数据包路由到拓扑距离最近的服务器。

Anycast 路由的工作原理：

1. CDN 提供商从多个 PoP 位置同时通过 BGP 宣告同一段 IP 地址前缀
2. 互联网骨干路由器根据 BGP 路径选择算法，将流量路由到最近的宣告点
3. 用户数据包自然地被路由到网络拓扑上最近的 PoP

Anycast 的核心优势在于：无需 DNS 调度即可实现就近接入；故障转移速度极快，当某个 PoP 停止 BGP 宣告后，流量在数秒内自动切换到下一个最近的节点；天然具备 DDoS 防护能力，攻击流量被分散到全球各个节点。

2.3 DNS 路由与 Anycast 路由对比

graph TB
    subgraph DNS路由
        U1[用户] -->|1. DNS 查询| DNS[CDN DNS / GSLB]
        DNS -->|2. 返回最近 PoP IP| U1
        U1 -->|3. 连接 PoP-A IP:1.1.1.1| PA[PoP-A<br/>1.1.1.1]
        PB[PoP-B<br/>2.2.2.2]
        PC[PoP-C<br/>3.3.3.3]
    end

    subgraph Anycast路由
        U2[用户] -->|1. 直接连接<br/>共享 IP:4.4.4.4| Router[互联网路由]
        Router -->|BGP 最短路径| PD[PoP-D<br/>4.4.4.4]
        PE[PoP-E<br/>4.4.4.4]
        PF[PoP-F<br/>4.4.4.4]
    end

    style DNS fill:#bbdefb
    style Router fill:#c8e6c9

以下是两种路由方案的详细对比：

实际生产中，许多 CDN 提供商会将两种方案结合使用。例如 Cloudflare 以 Anycast 为主，同时在 DNS 层面进行流量调度；Akamai 以 DNS 路由为主，在特定场景下使用 Anycast。

三、缓存层级设计

缓存是 CDN 的核心功能。合理的缓存层级设计能够在缓存命中率、内容新鲜度和源站负载之间取得最佳平衡。

3.1 多级缓存架构

现代 CDN 通常采用三到四级的缓存层次结构：

第一级：边缘缓存（Edge Cache）：位于每个 PoP 内部，直接服务用户请求。边缘缓存的容量有限（通常为 SSD 存储），缓存的内容以热点数据为主。边缘缓存的命中率通常在 85% 至 95% 之间。

第二级：区域缓存（Regional / Mid-tier Cache）：服务于一个区域内的多个边缘 PoP。当边缘缓存未命中时，请求被转发到区域缓存。区域缓存的存储容量更大，能够缓存更多的长尾内容。

第三级：源站护盾（Origin Shield）：通常只有一个或少数几个节点，作为所有回源请求的集中出口。源站护盾的主要价值在于请求合并（Request Coalescing）：当多个边缘节点同时回源请求同一资源时，源站护盾只向源站发送一次请求。

第四级：源站（Origin）：内容的权威来源。在理想状态下，源站只需处理极少量的回源请求。

3.2 缓存键设计

缓存键（Cache Key）决定了如何唯一标识一个缓存对象。默认的缓存键通常由请求方法、主机名和路径组成，但实际场景中往往需要更精细的控制。

常见的缓存键变体因素：

• 查询参数：?page=1&sort=name 是否参与缓存键？部分参数（如排序、分页）需要区分，而分析追踪参数（如 utm_source）应当忽略。
• 请求头：Accept-Encoding（区分 Brotli / Gzip 版本）、Accept-Language（区分语言版本）等。
• Cookie：某些个性化内容需要根据 Cookie 区分缓存版本，但这会严重降低命中率。
• 设备类型：移动端和桌面端可能需要不同的缓存版本。

3.3 缓存控制头

HTTP 缓存控制依赖一组标准化的响应头：

# Nginx 源站缓存控制头配置示例
location /static/ {
    # 静态资源：使用内容哈希指纹，长期缓存
    add_header Cache-Control "public, max-age=31536000, immutable";
    add_header Vary "Accept-Encoding";
}

location /api/products {
    # API 数据：允许 CDN 缓存 60 秒，客户端不缓存
    # s-maxage 仅对共享缓存（CDN）生效
    add_header Cache-Control "public, s-maxage=60, max-age=0";
    # 过期后允许使用旧版本 10 秒，同时后台刷新
    add_header Cache-Control "stale-while-revalidate=10";
    # 源站故障时允许使用旧版本 1 小时
    add_header Cache-Control "stale-if-error=3600";
}

location /api/user/profile {
    # 用户个性化数据：禁止 CDN 缓存
    add_header Cache-Control "private, no-store";
}

关键缓存指令解析：

• max-age：资源在客户端和共享缓存中的最大缓存时间（秒）
• s-maxage：仅对共享缓存（CDN、代理）生效，覆盖 max-age
• stale-while-revalidate：缓存过期后，允许先返回旧版本，同时异步向源站重新验证
• stale-if-error：当源站不可用时，允许返回已过期的缓存内容
• immutable：告知客户端此资源永不改变，避免条件请求
• no-store：禁止任何缓存存储
• private：仅允许客户端缓存，禁止共享缓存

3.4 Varnish 缓存配置

Varnish 是高性能的 HTTP 反向代理和缓存服务器，广泛应用于 CDN 边缘节点。以下是一个典型的 Varnish 配置：

# Varnish VCL 配置示例
vcl 4.1;

backend origin {
    .host = "origin.example.com";
    .port = "443";
    .ssl = true;
    .connect_timeout = 5s;
    .first_byte_timeout = 15s;
    .between_bytes_timeout = 5s;
    .probe = {
        .url = "/health";
        .interval = 10s;
        .timeout = 3s;
        .threshold = 3;
        .window = 5;
    }
}

sub vcl_recv {
    # 规范化查询参数：移除分析追踪参数
    if (req.url ~ "[?&](utm_source|utm_medium|utm_campaign|fbclid)=") {
        set req.url = regsuball(req.url,
            "([?&])(utm_source|utm_medium|utm_campaign|fbclid)=[^&]*", "");
        set req.url = regsub(req.url, "[?&]$", "");
    }

    # 规范化 Accept-Encoding
    if (req.http.Accept-Encoding) {
        if (req.http.Accept-Encoding ~ "br") {
            set req.http.Accept-Encoding = "br";
        } elsif (req.http.Accept-Encoding ~ "gzip") {
            set req.http.Accept-Encoding = "gzip";
        } else {
            unset req.http.Accept-Encoding;
        }
    }

    # 对静态资源移除 Cookie 以提升命中率
    if (req.url ~ "\.(css|js|png|jpg|jpeg|gif|ico|svg|woff2|woff|ttf)$") {
        unset req.http.Cookie;
        return (hash);
    }
}

sub vcl_backend_response {
    # 为没有缓存头的静态资源设置默认 TTL
    if (bereq.url ~ "\.(css|js|png|jpg|jpeg|gif|ico|svg|woff2)$"
        && !beresp.http.Cache-Control) {
        set beresp.ttl = 7d;
        set beresp.http.Cache-Control = "public, max-age=604800";
    }

    # 设置 Grace 期间（stale-while-revalidate 等效）
    set beresp.grace = 1h;

    # 为源站错误设置短 TTL 的负缓存
    if (beresp.status >= 500) {
        set beresp.ttl = 5s;
        set beresp.grace = 30s;
        return (deliver);
    }
}

sub vcl_hash {
    hash_data(req.url);
    hash_data(req.http.Host);
    # 将 Accept-Encoding 加入缓存键
    if (req.http.Accept-Encoding) {
        hash_data(req.http.Accept-Encoding);
    }
    return (lookup);
}

四、静态内容分发

静态内容分发是 CDN 最基础也是最成熟的功能。合理的静态资源策略可以显著提升页面加载性能。

4.1 静态资源类型与特征

CDN 分发的静态资源主要包括以下类型：

• 网页资源：HTML、CSS、JavaScript 文件。CSS 和 JS 通常使用内容哈希指纹实现长期缓存。
• 图片：JPEG、PNG、WebP、AVIF 等格式。图片通常占据网页总流量的 50% 以上。
• 字体：WOFF2、WOFF 格式的 Web 字体。字体文件对跨域策略敏感，需要正确配置 CORS。
• 视频：HLS（HTTP Live Streaming）和 DASH（Dynamic Adaptive Streaming over HTTP）分片。视频是 CDN 流量的最大组成部分。
• 文档：PDF、Office 文档等可下载文件。

4.2 内容指纹与长期缓存

内容指纹（Content Fingerprinting）是一种将文件内容的哈希值嵌入 URL 的技术。当文件内容变化时，URL 随之改变，从而自动使旧缓存失效。这种方式允许设置极长的缓存时间（如一年），而不必担心用户获取到过期内容。

# 构建工具生成的指纹文件名示例
app.a1b2c3d4.js        # JavaScript 主文件
styles.e5f6g7h8.css    # CSS 样式文件
logo.i9j0k1l2.png      # 图片资源

# 对应的 HTML 引用
# <script src="/assets/app.a1b2c3d4.js"></script>
# <link rel="stylesheet" href="/assets/styles.e5f6g7h8.css">

4.3 压缩策略

传输压缩是减少带宽消耗和提升加载速度的关键手段。

Brotli 压缩：Google 开发的压缩算法，压缩率比 Gzip 高 15% 至 25%。Brotli 在压缩等级 4 至 6 时提供了最佳的压缩率与速度平衡。现代浏览器在 HTTPS 连接下均支持 Brotli。

Gzip 压缩：传统压缩方案，兼容性最广。作为 Brotli 的降级方案使用。

# Nginx 压缩配置
# Brotli 压缩（需要 ngx_brotli 模块）
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/javascript
             application/json image/svg+xml application/xml
             text/xml application/x-javascript text/javascript;
brotli_min_length 256;

# Gzip 压缩（作为降级方案）
gzip on;
gzip_comp_level 6;
gzip_types text/plain text/css application/javascript
           application/json image/svg+xml application/xml;
gzip_min_length 256;
gzip_vary on;

需要注意的是，对于已经压缩的格式（如 JPEG、PNG、WOFF2、视频文件），不应再进行传输压缩，否则反而会增加 CPU 开销而几乎不减少体积。

4.4 HTTP/2 与 HTTP/3

HTTP/2：引入了多路复用（Multiplexing）、头部压缩（HPACK）、服务器推送（Server Push）等特性。多路复用允许在单个 TCP 连接上并行传输多个请求和响应，消除了 HTTP/1.1 的队头阻塞（Head-of-Line Blocking）问题。

HTTP/3（QUIC）：基于 UDP 的传输协议，解决了 TCP 层面的队头阻塞问题。当某个流的数据包丢失时，不会阻塞其他流的传输。QUIC 还内置了 TLS 1.3，实现了 0-RTT 或 1-RTT 的连接建立。对于高丢包率的网络环境（如移动网络），HTTP/3 的性能提升尤为明显。

4.5 最优静态内容响应头

# Nginx 静态资源最优响应头配置
server {
    listen 443 ssl http2;
    server_name cdn.example.com;

    # 启用 HTTP/3
    listen 443 quic reuseport;
    add_header Alt-Svc 'h3=":443"; ma=86400';

    # 带内容哈希的静态资源：长期缓存
    location ~* \.([0-9a-f]{8,})\.(css|js|woff2|svg)$ {
        expires 365d;
        add_header Cache-Control "public, max-age=31536000, immutable";
        add_header Vary "Accept-Encoding";
        add_header X-Content-Type-Options "nosniff";
        add_header Cross-Origin-Resource-Policy "cross-origin";
        access_log off;
    }

    # 图片资源
    location ~* \.(jpg|jpeg|png|gif|webp|avif|ico)$ {
        expires 30d;
        add_header Cache-Control "public, max-age=2592000";
        add_header Vary "Accept";
        # 允许跨域访问图片
        add_header Access-Control-Allow-Origin "*";
        access_log off;
    }

    # 字体资源（CORS 必需）
    location ~* \.(woff2|woff|ttf|otf|eot)$ {
        expires 365d;
        add_header Cache-Control "public, max-age=31536000, immutable";
        add_header Access-Control-Allow-Origin "*";
        add_header Cross-Origin-Resource-Policy "cross-origin";
        access_log off;
    }
}

五、动态内容加速

静态内容可以通过缓存解决延迟问题，但动态内容（如 API 响应、个性化页面）无法被长期缓存。CDN 对动态内容的加速依赖于网络层面的优化。

5.1 TCP 优化

连接复用（Connection Reuse）：边缘节点与源站之间维护一个持久连接池（Persistent Connection Pool）。用户的新请求可以复用已有的 TCP 连接，避免每次请求都进行 TCP 三次握手和 TLS 协商。

TCP 快速打开（TCP Fast Open，TFO）：允许在 TCP SYN 包中携带数据，减少一个 RTT 的延迟。边缘节点与源站之间的连接可以利用 TFO 加速建连。

拥塞控制调优：传统的 TCP 拥塞控制算法（如 Cubic）在高延迟链路上表现欠佳。CDN 提供商通常使用 BBR（Bottleneck Bandwidth and Round-trip propagation time）算法，它通过主动探测瓶颈带宽和 RTT 来优化吞吐量。

# Linux 内核 TCP 优化参数
# 启用 BBR 拥塞控制
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# 启用 TCP Fast Open（客户端 + 服务端）
net.ipv4.tcp_fastopen = 3

# 增大 TCP 缓冲区
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# 启用窗口缩放
net.ipv4.tcp_window_scaling = 1

# 减少 TIME_WAIT 状态的影响
net.ipv4.tcp_tw_reuse = 1

5.2 路由优化

互联网上的默认路由通常基于 BGP 的最短自治系统路径（AS Path），但最短路径不一定是最快路径。CDN 提供商通过主动探测全球网络状况，选择延迟最低、丢包率最低的路径。

Cloudflare 的 Argo Smart Routing 和 Akamai 的 SureRoute 都是此类技术的代表。它们在全球骨干网络中建立私有的网络覆盖（Overlay Network），绕过拥塞的公共互联网链路。

5.3 动态内容组装

部分 CDN 支持在边缘节点进行动态内容组装（Edge-Side Includes，ESI）。页面中不变的部分从缓存获取，动态部分从源站实时获取，在边缘节点完成拼装后返回给用户。

<!-- ESI 模板示例 -->
<html>
<head>
    <title>商品页面</title>
    <!-- 静态 CSS：从缓存获取 -->
    <link rel="stylesheet" href="/static/styles.css">
</head>
<body>
    <!-- 页面头部：缓存 1 小时 -->
    <esi:include src="/fragments/header" maxwait="500"/>

    <!-- 商品信息：缓存 5 分钟 -->
    <esi:include src="/api/product/12345" maxwait="1000"/>

    <!-- 用户个性化推荐：不缓存 -->
    <esi:include src="/api/recommendations?user=current" maxwait="2000"/>

    <!-- 页面底部：缓存 1 天 -->
    <esi:include src="/fragments/footer" maxwait="500"/>
</body>
</html>

5.4 协议优化

HTTP/2 Server Push：源站可以在响应 HTML 页面时主动推送页面所需的 CSS 和 JS 资源，减少浏览器发现并请求这些资源的延迟。但由于实现复杂和缓存判断困难，Server Push 在实践中已逐渐被 103 Early Hints 取代。

103 Early Hints：服务器在生成最终响应之前，先发送一个 103 状态码的临时响应，包含 Link 头部指示浏览器预加载关键资源。CDN 边缘节点可以缓存这些 Hint 信息并立即返回给浏览器，无需等待源站响应。

# 103 Early Hints 配置示例
location / {
    # 边缘节点立即返回 Early Hints
    add_header Link "</css/main.css>; rel=preload; as=style" early;
    add_header Link "</js/app.js>; rel=preload; as=script" early;
    add_header Link "</fonts/sans.woff2>; rel=preload; as=font; crossorigin" early;
    proxy_pass http://origin_upstream;
}

六、HTTPS 与 TLS 边缘管理

在 HTTPS 普及的今天，TLS 处理已成为 CDN 的核心功能。CDN 在边缘节点终止 TLS 连接，使用户无需与远端源站进行 TLS 握手。

6.1 TLS 边缘终止

TLS 终止（TLS Termination）是指在 CDN 边缘节点完成 TLS 握手和加解密操作。用户与边缘节点之间使用 HTTPS 加密传输，边缘节点与源站之间可以使用独立的 TLS 连接或 HTTP 明文连接（取决于安全策略）。

TLS 终止的核心价值在于：TLS 握手需要多次 RTT，在边缘终止可以将握手 RTT 从数百毫秒降至个位数毫秒。

6.2 大规模证书管理

大型 CDN 提供商需要管理数百万域名的 TLS 证书。这涉及以下技术挑战：

证书签发自动化：通过 ACME 协议（如 Let’s Encrypt）自动签发和续期证书。CDN 需要支持 HTTP-01 和 DNS-01 验证方式。

证书存储与分发：数百万证书需要在全球数百个 PoP 节点间高效同步。Cloudflare 使用基于 Keyless SSL 的架构，将私钥存储在集中式的密钥服务器上，边缘节点无需存储私钥。

SNI（Server Name Indication）：SNI 是 TLS 扩展，允许客户端在握手阶段告知服务器请求的域名。边缘节点根据 SNI 选择对应的证书。没有 SNI 的情况下，每个 IP 地址只能绑定一个证书。

6.3 OCSP Stapling

在线证书状态协议（Online Certificate Status Protocol，OCSP）用于验证证书是否已被吊销。传统方式下，浏览器需要向 CA 的 OCSP 响应器发送查询请求，增加了额外的延迟。

OCSP Stapling 让服务器预先获取并缓存 OCSP 响应，在 TLS 握手时将其”装订”（Staple）在证书链中一起发送给客户端。客户端无需再单独查询 OCSP 响应器。

6.4 TLS 1.3 优化

TLS 1.3 相比 TLS 1.2 有显著的性能和安全改进：

• 1-RTT 握手：TLS 1.3 将握手缩减为 1 个 RTT（TLS 1.2 需要 2 个 RTT）
• 0-RTT 恢复：对于曾经连接过的客户端，TLS 1.3 支持 0-RTT 恢复，在第一个数据包中即可携带应用数据
• 前向保密：TLS 1.3 强制使用临时密钥交换（Ephemeral Diffie-Hellman），确保即使长期密钥泄露也不影响历史会话的安全性
• 移除不安全算法：移除了 RC4、DES、3DES、MD5 等已知不安全的算法

# Nginx TLS 最优配置
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

# TLS 1.3 密码套件
ssl_conf_command Ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256;

# TLS 1.2 密码套件（降级方案）
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;

# ECDSA 证书（比 RSA 更快）
ssl_certificate /etc/ssl/certs/example.com.ecdsa.pem;
ssl_certificate_key /etc/ssl/private/example.com.ecdsa.key;

# 会话恢复（支持 0-RTT）
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets on;
ssl_early_data on;  # 启用 0-RTT

# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/certs/ca-chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

# HSTS
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

6.5 0-RTT 安全考量

0-RTT 虽然提升了性能，但存在重放攻击（Replay Attack）的风险：攻击者可以捕获并重放 0-RTT 数据包。因此，0-RTT 应当仅用于幂等请求（如 GET），对于非幂等操作（如 POST）必须禁止使用 0-RTT 数据。CDN 边缘节点通常会在 0-RTT 请求中添加 Early-Data: 1 头部，源站据此判断是否接受该请求。

七、Cloudflare 架构解析

Cloudflare 是全球最大的 CDN 和安全服务提供商之一，其架构设计哲学在业界独树一帜。

7.1 架构哲学：每台服务器运行所有服务

Cloudflare 采用了一种”每台服务器运行所有服务”（Every Server Runs Every Service）的同构架构。与传统 CDN 将不同功能部署在不同服务器上不同，Cloudflare 的每台边缘服务器都运行完整的服务栈：DNS 解析、HTTP 代理、缓存、WAF、DDoS 防护、Workers 运行时等。

这种设计的优势包括： - 简化运维：只需管理一种服务器配置，部署和升级更加简单 - 资源利用率高：不同服务在不同时间段的负载不同，共享资源避免了单一服务的资源浪费 - 弹性扩展：新增 PoP 节点时只需部署标准化的服务器，无需为不同功能单独规划容量

7.2 Anycast 网络

Cloudflare 的所有服务都通过 Anycast 网络对外提供。全球所有数据中心宣告相同的 IP 地址前缀，用户的请求自动被路由到最近的数据中心。

Cloudflare 的 Anycast 实现细节： - 每个数据中心与本地 ISP 和 IXP 建立 BGP 对等关系 - 使用 BGP Community 属性控制路由传播范围 - 通过 ECMP（Equal-Cost Multi-Path）在数据中心内部实现负载均衡 - 使用 Maglev 一致性哈希算法将流量分配到具体的服务器

7.3 Workers：边缘计算平台

Cloudflare Workers 是一个基于 V8 隔离（Isolate）的无服务器计算平台，运行在 Cloudflare 全球网络的每个数据中心。

Workers 的核心技术特点： - V8 Isolate：使用 V8 引擎的 Isolate 而非容器或虚拟机实现租户隔离。Isolate 的启动时间在微秒级别，远快于容器的秒级启动。 - Service Worker API：Workers 使用标准的 Web Service Worker API，开发者可以拦截和处理 HTTP 请求。 - KV 存储：提供全球分布的键值存储（Workers KV），最终一致性模型，适合读多写少的场景。 - Durable Objects：提供强一致性的有状态对象，每个对象在全球只有一个实例，适合需要协调和一致性的场景。 - R2 存储：S3 兼容的对象存储，无出口流量费用。

7.4 Argo Smart Routing

Argo Smart Routing 是 Cloudflare 的智能路由优化服务。它利用 Cloudflare 的全球网络作为私有骨干网，为请求选择最快的传输路径。

工作原理：

1. Cloudflare 持续在全球节点之间进行延迟和丢包率探测
2. 基于实时数据构建全球网络拓扑图
3. 使用路径优化算法为每个请求选择延迟最低的路径
4. 请求在 Cloudflare 的内部网络中传输，避免公共互联网的拥塞和路由问题

根据 Cloudflare 公布的数据，Argo Smart Routing 平均可以将首字节时间（Time to First Byte，TTFB）缩短约 30%。

八、Akamai 架构解析

Akamai 是 CDN 行业的先驱和全球最大的分布式计算平台之一，其架构设计理念与 Cloudflare 存在显著差异。

8.1 架构哲学：大规模分布式平台

Akamai 的核心设计理念是”将服务器部署到网络的最后一英里”。Akamai 在全球超过 4000 个位置部署了超过 36 万台服务器，深入到各地 ISP 的网络内部。这种极度分散的部署策略使 Akamai 能够在网络拓扑上与终端用户保持极短的距离。

与 Cloudflare 的同构架构不同，Akamai 的不同服务器承担不同的角色：

• 边缘服务器（Edge Server）：部署在 ISP 网络内部，负责终端用户的内容分发
• 中间层服务器（Midgress / Parent Server）：位于区域性数据中心，为边缘服务器提供二级缓存
• 映射服务器（Mapping Server）：运行 Akamai 的智能 DNS 系统，负责将用户请求路由到最优边缘服务器
• 管理服务器（Management Server）：处理配置下发、日志收集、监控等运维任务

8.2 智能平台与 EdgeCompute

Akamai 的智能平台（Intelligent Platform）是其技术核心，包含以下关键系统：

全球状态监控（Global Traffic Management）：实时收集全球网络状态、服务器负载、BGP 路由变化等信息，并据此做出路由决策。

EdgeCompute：Akamai 的边缘计算平台，支持在边缘运行 JavaScript（EdgeWorkers）和 Wasm 程序。与 Cloudflare Workers 不同，Akamai EdgeWorkers 可以访问更丰富的上下文信息，如用户的网络运营商、设备类型等。

8.3 SureRoute 优化

SureRoute 是 Akamai 的路径优化技术，与 Cloudflare 的 Argo Smart Routing 类似。其工作原理：

1. Akamai 在全球服务器之间持续进行”竞速”（Race）测试
2. 对于每个源站，系统维护多条候选路径
3. 每条路径的延迟、丢包率和可用性被实时监控
4. 请求被路由到当前性能最优的路径上

8.4 与 Cloudflare 的架构对比

两种架构没有绝对的优劣之分。Cloudflare 的同构架构适合快速迭代和全球统一的服务体验；Akamai 的大规模异构部署则在极端性能场景（如大规模视频直播）中表现更优。

九、缓存失效策略

缓存的生命周期管理是 CDN 运维中的核心问题。如何在保证内容新鲜度的同时最大化缓存命中率，是每个 CDN 使用者面临的挑战。

9.1 清除机制

CDN 提供多种缓存清除（Purge）机制：

单 URL 清除：清除特定 URL 的缓存内容。这是最精确的清除方式，对系统的影响最小。

通配符清除：使用通配符模式批量清除。例如 /images/* 可以清除 /images/ 路径下的所有缓存。

标签清除（Tag-based Purge）：通过缓存标签对缓存对象进行分组，清除时指定标签即可批量清除所有关联对象。这是最灵活也是最推荐的清除方式。

全量清除：清除整个域名或账户下的所有缓存。这是一种破坏性操作，会导致大量回源请求，应当谨慎使用。

9.2 TTL 过期与事件驱动失效

TTL 过期：最基本的缓存失效方式。通过 Cache-Control: max-age 或 Expires 头部设置缓存的有效期。优点是实现简单、无需额外通信；缺点是在 TTL 到期之前，用户可能获取到过期内容。

事件驱动失效：当源站内容更新时，主动通知 CDN 清除对应的缓存。这种方式需要在内容管理系统中集成 CDN 的清除 API。优点是内容更新后可以立即清除旧缓存；缺点是增加了系统复杂度。

实践中通常将两种方式结合使用：设置合理的 TTL 作为兜底，关键内容更新时主动触发清除。

9.3 代理键与缓存标签

代理键（Surrogate Key）也称缓存标签（Cache Tag），是为缓存对象附加的元数据标签。一个缓存对象可以关联多个标签，清除时指定标签可以一次性清除所有关联对象。

应用场景：

• 电商平台：商品详情页标记 product-123、category-shoes、brand-nike 三个标签。当 Nike 品牌信息更新时，清除 brand-nike 标签即可一次性清除所有 Nike 相关页面的缓存。
• 新闻网站：文章页面标记 article-456、author-wang、topic-tech 标签。当作者信息更新时，通过 author-wang 标签清除该作者所有文章的缓存。

# 在源站响应中设置缓存标签
location /products/ {
    # Surrogate-Key 头部用于标签清除
    # 多个标签以空格分隔
    add_header Surrogate-Key "product-$product_id category-$category brand-$brand";
    add_header Cache-Control "public, s-maxage=3600";
    proxy_pass http://product_service;
}

9.4 Stale-While-Revalidate 模式

stale-while-revalidate 是一种允许在缓存过期后继续使用旧缓存的策略，同时在后台异步向源站发起重新验证请求。

这种模式的核心价值在于：用户始终能够快速获得响应（即使是稍微过期的内容），而缓存在后台完成更新。对于新鲜度要求不是极端严格的场景，这是一种非常实用的策略。

9.5 缓存惊群防护

当某个热点缓存过期时，可能有大量请求同时穿透到源站，形成缓存惊群（Cache Stampede）或称”雷群效应”（Thundering Herd）。

防护措施包括：

请求合并（Request Coalescing / Collapsing）：当多个请求同时请求同一个已过期的缓存对象时，只向源站发送一个请求，其他请求等待该请求的响应。

锁机制刷新（Lock-based Refresh）：使用分布式锁确保同一时刻只有一个请求负责刷新缓存，其他请求返回旧版本的缓存内容。

随机化 TTL：为缓存的 TTL 添加随机抖动（Jitter），避免大量缓存在同一时刻同时过期。

# Nginx 请求合并配置
proxy_cache_lock on;
proxy_cache_lock_timeout 5s;
proxy_cache_lock_age 5s;

# 配合 stale-while-revalidate 使用
proxy_cache_use_stale updating error timeout http_500 http_502 http_503 http_504;
proxy_cache_background_update on;

9.6 缓存清除 API 调用

以下是主流 CDN 的缓存清除 API 调用示例：

# Cloudflare - 按 URL 清除
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \
  -H "Authorization: Bearer {api_token}" \
  -H "Content-Type: application/json" \
  --data '{
    "files": [
      "https://example.com/css/styles.css",
      "https://example.com/js/app.js"
    ]
  }'

# Cloudflare - 按缓存标签清除
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \
  -H "Authorization: Bearer {api_token}" \
  -H "Content-Type: application/json" \
  --data '{
    "tags": ["product-123", "category-shoes"]
  }'

# Fastly - 按 Surrogate-Key 清除
curl -X POST "https://api.fastly.com/service/{service_id}/purge/{surrogate_key}" \
  -H "Fastly-Key: {api_key}"

# Akamai - 按 URL 清除（使用 CCU v3 API）
curl -X POST "https://api.ccu.akamai.com/ccu/v3/invalidate/url/production" \
  -H "Content-Type: application/json" \
  --data '{
    "objects": [
      "https://example.com/images/logo.png",
      "https://example.com/products/item-456"
    ]
  }'

十、边缘计算

边缘计算（Edge Computing）是 CDN 技术的自然延伸：既然 CDN 已经在全球部署了服务器，为何不在这些服务器上运行业务逻辑？

10.1 边缘计算概述

边缘计算允许开发者在 CDN 的 PoP 节点上运行自定义代码。请求无需回源到集中式数据中心，在边缘即可完成处理。这将延迟从数百毫秒降至个位数毫秒。

边缘计算与传统无服务器计算（Serverless）的关键区别在于部署位置：传统 Serverless（如 AWS Lambda）运行在少数几个云区域的数据中心，而边缘计算运行在全球数百个 PoP 节点上。

10.2 典型应用场景

A/B 测试：在边缘节点根据用户标识或随机分组，将请求路由到不同的后端版本或修改响应内容。无需后端服务参与，延迟极低。

认证与鉴权：在边缘节点验证 JWT Token 或 API Key，拒绝未授权请求，避免无效请求到达源站。

个性化内容：根据用户的地理位置、设备类型、语言偏好等信息，在边缘定制响应内容。

地理围栏：根据用户 IP 的地理位置实现区域性内容访问控制。

请求改写与路由：在边缘修改请求路径、添加头部、重定向等操作。

安全防护：实现速率限制、Bot 检测、IP 黑名单等安全功能。

10.3 主流边缘计算平台

Cloudflare Workers：基于 V8 Isolate，支持 JavaScript 和 WebAssembly。启动时间在 0 毫秒级别（无冷启动问题），全球 300 个以上数据中心部署。CPU 执行时间限制为 10 至 50 毫秒（付费版更高）。

AWS Lambda@Edge：与 CloudFront CDN 集成，运行在 AWS 全球 13 个区域的 200 个以上边缘位置。支持 Node.js 和 Python 运行时。冷启动时间可能达到数百毫秒。

Akamai EdgeWorkers：运行在 Akamai 全球 4000 个以上位置。支持 JavaScript 运行时，可以访问 Akamai 特有的请求元数据（如用户设备信息、网络运营商等）。

Deno Deploy：基于 V8 Isolate 的边缘计算平台，支持 TypeScript / JavaScript。强调与 Web 标准的兼容性。

10.4 边缘计算的限制

边缘计算并非万能，存在以下限制：

• 执行时间：通常限制在毫秒级别（10-50ms CPU 时间），不适合复杂计算任务
• 内存限制：通常在 128MB 以内
• 网络访问限制：部分平台限制出站连接数和并发请求数
• 存储限制：边缘节点的持久化存储容量有限
• 调试困难：分布在全球的运行时使调试和日志收集变得复杂
• 数据一致性：边缘节点之间的数据同步存在延迟，全局一致性难以保证

10.5 边缘 Worker 示例：A/B 测试

以下是使用 Cloudflare Workers 实现 A/B 测试的完整示例：

// Cloudflare Workers A/B 测试示例
const defined_EXPERIMENT = {
  name: "homepage-redesign",
  variants: [
    { name: "control", weight: 50, backend: "https://origin-a.example.com" },
    { name: "treatment", weight: 50, backend: "https://origin-b.example.com" }
  ],
  cookie_name: "ab_variant",
  cookie_max_age: 86400 * 30  // 30 天
};

addEventListener("fetch", (event) => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  const url = new URL(request.url);

  // 仅对首页进行 A/B 测试
  if (url.pathname !== "/") {
    return fetch(request);
  }

  // 检查用户是否已分组
  const cookies = parseCookies(request.headers.get("Cookie") || "");
  let variant = cookies[defined_EXPERIMENT.cookie_name];

  // 如果用户未分组，进行随机分组
  let needSetCookie = false;
  if (!variant || !isValidVariant(variant)) {
    variant = assignVariant();
    needSetCookie = true;
  }

  // 获取对应变体的后端地址
  const variantConfig = defined_EXPERIMENT.variants.find(
    (v) => v.name === variant
  );
  const backendUrl = variantConfig.backend + url.pathname + url.search;

  // 向对应后端发起请求
  const response = await fetch(backendUrl, {
    method: request.method,
    headers: request.headers,
    body: request.body
  });

  // 构造响应
  const modifiedResponse = new Response(response.body, response);

  // 设置分组 Cookie
  if (needSetCookie) {
    modifiedResponse.headers.append(
      "Set-Cookie",
      `${defined_EXPERIMENT.cookie_name}=${variant}; Path=/; Max-Age=${defined_EXPERIMENT.cookie_max_age}; Secure; HttpOnly; SameSite=Lax`
    );
  }

  // 添加分组信息头部（供分析使用）
  modifiedResponse.headers.set("X-AB-Variant", variant);
  modifiedResponse.headers.set("X-AB-Experiment", defined_EXPERIMENT.name);

  return modifiedResponse;
}

function assignVariant() {
  const random = Math.random() * 100;
  let cumulative = 0;
  for (const variant of defined_EXPERIMENT.variants) {
    cumulative += variant.weight;
    if (random < cumulative) {
      return variant.name;
    }
  }
  return defined_EXPERIMENT.variants[0].name;
}

function isValidVariant(name) {
  return defined_EXPERIMENT.variants.some((v) => v.name === name);
}

function parseCookies(cookieHeader) {
  const cookies = {};
  cookieHeader.split(";").forEach((pair) => {
    const [key, value] = pair.trim().split("=");
    if (key) cookies[key] = value;
  });
  return cookies;
}

十一、工程案例：视频流媒体平台的 CDN 架构

本节以一个面向全球用户的视频流媒体平台为工程案例，完整分析其 CDN 架构设计过程。

11.1 业务需求

该平台的核心需求如下：

• 全球覆盖：用户分布在北美、欧洲、亚太等主要区域，需要在全球范围内提供低延迟的播放体验
• 自适应码率（Adaptive Bitrate，ABR）：支持 HLS 和 DASH 协议，根据用户网络状况自动切换清晰度
• 低启播延迟：用户点击播放后，首帧画面在 2 秒内呈现
• 高并发：支持百万级同时在线观看，峰值期间单视频可能有数十万用户同时观看
• 直播支持：支持低延迟直播（端到端延迟低于 5 秒）

11.2 CDN 架构设计

多 CDN 策略

该平台采用多 CDN 策略，同时使用 Akamai、Cloudflare 和 AWS CloudFront 三家 CDN。这一决策基于以下考虑：

• 容灾冗余：任一 CDN 故障不影响整体服务
• 覆盖互补：不同 CDN 在不同区域的性能表现各有优劣
• 成本优化：通过竞争压价和流量分配优化总体成本
• 避免供应商锁定：保持技术选型的灵活性

流量调度架构

# 多 CDN 流量调度配置
traffic_routing:
  strategy: "performance_based"
  providers:
    - name: "akamai"
      weight: 45
      regions:
        - north_america: 50
        - europe: 40
        - asia: 30
    - name: "cloudflare"
      weight: 35
      regions:
        - north_america: 30
        - europe: 40
        - asia: 40
    - name: "cloudfront"
      weight: 20
      regions:
        - north_america: 20
        - europe: 20
        - asia: 30

  health_check:
    interval: 30s
    timeout: 5s
    unhealthy_threshold: 3
    fallback_provider: "cloudflare"

  performance_thresholds:
    max_ttfb_ms: 200
    max_error_rate: 0.01
    min_throughput_mbps: 50

视频内容处理流水线

视频从上传到可播放经历以下处理流程：

1. 上传：视频文件上传至中心存储（如 AWS S3）
2. 转码：将原始视频转码为多种码率和分辨率（如 360p / 720p / 1080p / 4K）
3. 分片：将视频切割为固定时长的小分片（通常 2-6 秒），生成 HLS（m3u8）和 DASH（mpd）清单文件
4. 预热：将热门内容预推送至各 CDN 的边缘节点
5. 分发：用户请求通过 CDN 就近获取视频分片

缓存策略

# 视频平台 CDN 缓存策略
# 清单文件（m3u8 / mpd）：短缓存，保证快速更新
location ~* \.(m3u8|mpd)$ {
    add_header Cache-Control "public, s-maxage=2, max-age=1";
    add_header Surrogate-Key "manifest video-$video_id";
}

# 视频分片（ts / m4s）：长缓存，内容不变
location ~* \.(ts|m4s|mp4)$ {
    add_header Cache-Control "public, max-age=86400, immutable";
    add_header Surrogate-Key "segment video-$video_id quality-$quality";
}

# 缩略图和海报图
location ~* /thumbnails/ {
    add_header Cache-Control "public, max-age=3600";
    add_header Surrogate-Key "thumbnail video-$video_id";
}

11.3 直播场景的特殊处理

直播场景对 CDN 提出了额外的挑战：

超低延迟要求：直播的端到端延迟需要控制在 5 秒以内。传统 HLS 的 3 个分片缓冲（每片 6 秒）导致约 18 秒延迟，完全无法满足要求。

解决方案：

• 使用低延迟 HLS（LL-HLS）或低延迟 CMAF（LL-CMAF），将分片时长缩短至 1-2 秒，并支持部分分片（Partial Segment）传输
• CDN 边缘节点使用分块传输编码（Chunked Transfer Encoding），在分片生成完成之前就开始向用户推送数据
• 清单文件的缓存 TTL 设置为极短（0.5-1 秒），或使用 HTTP/2 Server Push 主动推送更新

流量突增应对：热门直播可能在瞬间吸引百万用户，源站生成的每个新分片会被所有边缘节点同时回源请求。通过源站护盾进行请求合并是关键：全球数百个边缘节点的回源请求被合并为一个请求。

11.4 监控与可观测性

该平台建立了完善的 CDN 监控体系：

关键指标：

• 缓存命中率（Cache Hit Ratio）：目标 > 95%
• 首字节时间（TTFB）：目标 < 100ms（P95）
• 视频启播时间（Video Start Time）：目标 < 2s（P95）
• 重缓冲率（Rebuffer Rate）：目标 < 0.5%
• 错误率（Error Rate）：目标 < 0.1%
• 带宽利用率：实时监控各 CDN 的带宽使用情况

监控架构：

• 客户端 SDK 上报播放质量数据（启播时间、卡顿次数、码率切换等）
• CDN 访问日志实时采集至日志分析平台
• 综合分析系统每 30 秒计算一次各区域、各 CDN 的性能指标
• 自动化流量调度系统根据实时指标动态调整 CDN 流量分配

{
  "monitoring_config": {
    "metrics": [
      {
        "name": "cache_hit_ratio",
        "source": "cdn_logs",
        "aggregation": "ratio",
        "alert_threshold": 0.90,
        "window": "5m"
      },
      {
        "name": "ttfb_p95",
        "source": "cdn_logs",
        "aggregation": "percentile_95",
        "alert_threshold_ms": 200,
        "window": "5m"
      },
      {
        "name": "video_start_time_p95",
        "source": "client_telemetry",
        "aggregation": "percentile_95",
        "alert_threshold_ms": 3000,
        "window": "5m"
      },
      {
        "name": "rebuffer_rate",
        "source": "client_telemetry",
        "aggregation": "ratio",
        "alert_threshold": 0.01,
        "window": "5m"
      },
      {
        "name": "error_rate_5xx",
        "source": "cdn_logs",
        "aggregation": "ratio",
        "alert_threshold": 0.005,
        "window": "1m"
      }
    ],
    "auto_failover": {
      "enabled": true,
      "trigger": "error_rate_5xx > 0.02 OR ttfb_p95 > 500",
      "action": "shift_traffic_to_backup_cdn",
      "cooldown": "10m"
    }
  }
}

11.5 经验总结

该视频平台在 CDN 架构实践中获得的关键经验：

多 CDN 是必需的：单一 CDN 存在单点故障风险。即便是全球顶级 CDN 提供商也会出现区域性故障。多 CDN 策略虽然增加了运维复杂度，但显著提升了整体可用性。

清单文件的缓存策略至关重要：视频分片可以长期缓存，但清单文件（m3u8 / mpd）的缓存必须非常短暂。清单文件缓存过长会导致播放器获取不到最新的分片信息。

预热比按需拉取更可靠：对于已知会有大量用户观看的热门内容（如首页推荐、新剧上线），提前将内容推送至边缘节点，可以避免大量并发回源导致的性能问题。

客户端监控不可替代：CDN 侧的监控只能反映服务端的状况，无法反映用户的真实体验。客户端上报的播放质量数据是衡量 CDN 效果的最终标准。

成本控制需要精细化：视频 CDN 的流量成本是运营成本的重要组成部分。通过选择合适的编码格式（如 AV1 比 H.264 节省 30-50% 带宽）、优化码率阶梯（Per-Title Encoding）、利用非高峰时段预热等手段，可以显著降低 CDN 成本。

十二、权衡总结

CDN 架构设计中包含大量需要权衡的决策点。以下从多个维度进行系统化总结。

12.1 关键架构决策权衡表

12.2 常见配置误区

误区一：对所有内容设置相同的缓存时间。不同类型的内容应当有不同的缓存策略。静态资源（带内容哈希）可以缓存一年，API 响应可能只缓存数秒，个性化内容则完全不应缓存。

误区二：忽略 Vary 头部。未正确设置 Vary 头部可能导致不同编码格式或语言版本的内容被错误地混合缓存，用户获取到错误的响应。

误区三：对动态内容完全不使用 CDN。即使不缓存内容，CDN 的 TCP 优化、TLS 边缘终止和路径优化对动态请求也有显著的加速效果。

误区四：缓存清除后不验证。缓存清除是异步操作，全球所有节点完成清除需要一定时间。发起清除请求后应当等待并验证各区域节点确实完成了清除。

误区五：忽略源站护盾。不启用源站护盾时，每个边缘节点的缓存未命中都会直接回源。对于流量分布广泛的场景，这可能导致源站承受巨大压力。

误区六：缓存含有 Set-Cookie 头部的响应。将包含 Set-Cookie 的响应缓存在 CDN 上可能导致用户收到其他用户的 Cookie，引发严重的安全和隐私问题。

12.3 性能优化检查清单

以下是一份 CDN 性能优化的检查清单，可用于评估现有 CDN 配置的优化程度：

缓存策略： - 静态资源是否使用内容哈希指纹并设置长期缓存？ - API 响应是否根据特征设置了合理的 s-maxage？ - 是否配置了 stale-while-revalidate 和 stale-if-error？ - 缓存命中率是否在 90% 以上？

传输优化： - 是否启用了 Brotli 压缩？ - 是否启用了 HTTP/2？是否评估了 HTTP/3？ - 是否配置了 preconnect 和 preload 资源提示？

TLS 优化： - 是否使用 TLS 1.3？ - 是否启用了 OCSP Stapling？ - 是否考虑使用 ECDSA 证书替代 RSA 证书？ - 是否配置了 HSTS？

可用性： - 是否配置了源站护盾？ - 是否评估了多 CDN 策略？ - CDN 故障时是否有降级方案？

安全： - 是否确保个性化内容标记为 private 或 no-store？ - 是否确保包含 Set-Cookie 的响应不被缓存？ - 是否配置了 X-Content-Type-Options: nosniff？

上一篇：消息队列架构

下一篇：连接池架构

参考资料

1. Nygren, E., Sitaraman, R. K., & Sun, J. “The Akamai Network: A Platform for High-Performance Internet Applications.” ACM SIGOPS Operating Systems Review, 2010.
2. Cloudflare. “How Cloudflare Works.” https://www.cloudflare.com/learning/cdn/what-is-a-cdn/
3. Fielding, R. et al. “Hypertext Transfer Protocol – HTTP/1.1.” RFC 7234 (Caching), 2014.
4. Bishop, M. “HTTP/3.” RFC 9114, 2022.
5. Iyengar, J. & Thomson, M. “QUIC: A UDP-Based Multiplexed and Secure Transport.” RFC 9000, 2021.
6. Rescorla, E. “The Transport Layer Security (TLS) Protocol Version 1.3.” RFC 8446, 2018.
7. Cloudflare. “Introducing Cloudflare Workers.” Cloudflare Blog, 2017.
8. Schlinker, B. et al. “Engineering Egress with Edge Fabric: Steering Oceans of Content to the World.” ACM SIGCOMM, 2017.
9. Calder, M. et al. “Analyzing the Performance of an Anycast CDN.” ACM IMC, 2015.
10. Fastly. “Surrogate Keys: Cache Invalidation Made Easy.” Fastly Documentation.
11. Grigorik, I. “High Performance Browser Networking.” O’Reilly Media, 2013.
12. Cloudflare. “Argo Smart Routing.” https://www.cloudflare.com/products/argo-smart-routing/