前言：为什么每个人都该懂一点 CDN

你每天打开的几乎每一个网站、每一段短视频、每一次点开的小程序，背后都有 CDN 在默默工作。它决定了页面是“秒开”还是“转圈半分钟”，决定了一次大促会不会因为流量洪峰而崩溃，也决定了一次 DDoS 攻击能否被挡在门外。

然而 CDN 又是一个“存在感很低”的技术：它工作得越好，用户越感觉不到它。直到某天它出问题——视频卡顿、图片裂图、接口超时——人们才会想起它的存在。

这份材料的目的是：让你系统地、从头到尾理解 CDN，既能和运维、架构师无障碍沟通，也能在需要时自己选型、配置甚至自建。无论你是开发者、运维、产品经理，还是单纯想搞懂“网速”背后发生了什么，都能有所收获。

全书路线图

1.1 一个让人抓狂的场景

想象一下：你在中国北京，想打开一个托管在美国洛杉矶的网站。你点的每一次请求，都要跨越太平洋，往返约 11,000 公里。光是信号在光纤里跑一个来回，物理极限就接近 110 毫秒（光速约 20 万公里/秒，光纤中约 2/3 光速）。这还没算上中间几十台路由器的转发、TCP 三次握手、TLS 握手的几十毫秒、服务器处理时间……于是你盯着白屏转圈，体验糟糕。

更糟的是“最后一跳”：就算服务器响应很快，数据包从国际出口到你家的 Wi-Fi，还可能经过拥堵的运营商骨干网。这种“慢”，不是服务器的问题，而是距离和链路的问题。

1.2 CDN 的定义

CDN（Content Delivery Network，内容分发网络）是一组分布在不同地理位置的服务器（称为边缘节点 / 边缘 POP）组成的网络。它的作用是：将网站的静态和动态内容缓存到离用户更近的节点上，使用户可以从“就近”的节点获取内容，从而减少延迟、提升访问速度、降低源站负载、增强可用性与安全性。

通俗地说：如果源站是“总仓库”，CDN 就是开在小区门口的“便利店”。大家不用每次都跑总仓库，楼下就能买到常用的东西；只有便利店没货时，才去总仓库补货。

1.3 没有 CDN 的世界 vs 有 CDN 的世界

1.4 CDN 能加速哪些内容？

• 静态内容：图片、CSS、JS、字体、压缩包、安装程序、文档——这类内容不变或很少变，最适合缓存，加速效果最明显。
• 流媒体：视频点播（VoD）、直播——通过分片（HLS/DASH）、转码、就近拉流大幅降低卡顿。
• 动态内容：API 接口、个性化页面——CDN 无法直接缓存，但可通过路由优化、协议优化、边缘计算提速（即“全站加速/DCDN”）。
• 下载与分发：大文件、软件更新、游戏补丁——靠多节点并行和就近下载。

1.5 动手试一试：距离如何影响延迟

信号在光纤中的传播速度约为 20 万公里/秒。下面这个计算器帮你直观感受“距离=延迟”。注意：这只是物理传播延迟下限，真实网络还要叠加路由、握手、排队等，通常乘以 1.5~3 倍。

1.5.x CDN 发展简史

理解来龙去脉，能帮你判断技术走向：

• 1990s 早期：网站靠“镜像站点”“缓存代理”缓解远距离访问，是 CDN 的雏形，但管理成本高。
• 1998 年：Akamai 成立，提出用大量分布式节点 + 智能调度做内容分发，奠定现代 CDN 商业模式。
• 2000s–2010s：视频、电商、社交爆发，CDN 成为标配；云厂商（AWS/Azure/GCP/阿里/腾讯）纷纷推出自有 CDN。
• 2010s 末至今：从“缓存”走向“安全+边缘计算”：WAF、DDoS、Bot 管理、边缘函数（Workers/Lambda@Edge）成为新增长点。
• 当下趋势：HTTP/3/QUIC 普及、AI 与边缘推理、一体化“边缘安全加速平台”、WebAssembly 可移植边缘运行时。

1.5.y 什么时候其实“不需要”CDN

CDN 不是银弹，以下场景它的收益有限，甚至可能不划算：

一句话：当用户和源站“离得远、量很大、内容可缓存”时，CDN 的回报最明显。

1.5.z 该不该上 CDN？一张决策清单

1. 用户是否跨地域/跨国？（是 → CDN 收益大）
2. 是否有大量静态/可缓存内容？（是 → 命中率会高）
3. 是否担心 DDoS/Web 攻击？（是 → CDN 安全能力有价值）
4. 源站带宽/算力是否紧张？（是 → CDN 替你扛）
5. 是否在意首屏与转化？（是 → 加速直接影响收入）

以上多数答“是”，就值得上 CDN。哪怕只是个人站点，免费层也能立刻受益。

1.6 本章小结

2.1 一次请求的生命周期

当你在浏览器输入 https://example.com/logo.png 并回车，到图片出现在屏幕上，在 CDN 世界里大致经历这几步：

1. DNS 解析与调度：把域名解析成“离你最近”的边缘节点 IP。
2. 建立连接：与边缘节点完成 TCP 三次握手、TLS 握手。
3. 节点查缓存：边缘节点检查本地是否已有这份资源的副本。
4. 命中（HIT）：直接把副本返回给你，请求到此结束。
5. 未命中（MISS）：节点回源站拉取内容，缓存后返回给你。

其中第 1~3 步决定了“你连的是哪台机器”，第 4~5 步决定了“内容从哪来”。下面逐一拆解。

2.2 DNS 与智能调度

CDN 的“就近”不是靠魔法，而是靠 DNS 调度。传统 DNS 只返回固定 IP；CDN 的权威 DNS 会在解析时，根据请求者的 IP 属地、节点负载、网络质量等，动态返回最优边缘节点的 IP。这种全局调度系统称为 GSLB（Global Server Load Balancing，全局负载均衡）。

常见调度技术

2.3 缓存机制：CDN 的灵魂

缓存是 CDN 提升性能的核心。理解它，要抓住几个关键概念：

• 缓存键（Cache Key）：用什么来标识“同一份内容”。通常是 域名 + URL 路径 + 查询参数（可配置忽略）。键相同才认为是同一份缓存。
• TTL（Time To Live，生存时间）：这份缓存最多保留多久。超时后下次请求视为未命中，需回源刷新。
• 命中（HIT）/ 未命中（MISS）：请求的资源在节点上是否已有有效副本。
• 分层缓存：边缘节点 → 区域节点 → 源站，形成多级缓存，减少回源率。

缓存策略示例（Nginx 风格）

# 默认缓存 1 小时；带 cookie 或登录态的不缓存
proxy_cache_valid 200 302 1h;
proxy_cache_valid 404 10m;
location ~* \.(jpg|png|css|js)$ {
    expires 30d;          # 浏览器侧缓存 30 天
    add_header Cache-Control "public, max-age=2592000";
}
location /api/ {
    proxy_cache_bypass $http_authorization;  # 带授权的请求不读缓存
}

2.4 回源（Origin Pull）

当边缘节点没有命中缓存，它就要向源站（Origin）请求内容，这个过程叫回源。回源越少越好，因为回源意味着延迟升高、源站压力增大。

• 被动回源（Pull）：用户请求触发时才去源站拉。最常见，源站无需主动推送。
• 主动推送（Push）：内容更新后由源站/控制台推送到边缘。适合大文件、可预期的热内容。
• 回源优化：合并回源（多个未命中请求只回源一次，即 request collapsing）、回源超时与重试、回源 Host/协议配置、源站健康检查。

2.5 边缘节点（Edge / POP）

POP（Point of Presence，接入点）是 CDN 在世界各地部署的边缘机房。一个成熟的 CDN 通常有数百到数千个 POP，覆盖各大洲、各国主要城市与运营商。POP 越多、越靠近用户，平均延迟越低。常见的选址考量：

• 地理覆盖：靠近人口与用户密集区。
• 运营商互联：与主流运营商、IX（互联网交换中心）直连，减少跨网结算。
• 容量与成本：机房带宽、电力、租金。

2.6 动手试一试：缓存命中模拟器

下面的模拟器模拟 20 次请求。假设一份资源的缓存 TTL 是 5 次请求。你可以观察“命中率”如何随 TTL 与并发变化。点击“发起一轮请求”。

2.7 本章小结

3.1 负载均衡：让流量去对的地方

CDN 的负载均衡分两层：

• GSLB（全局负载均衡）：跨地域/跨节点调度，决定用户连到哪个大区（见第 2 章）。
• LSLB（本地/局部负载均衡）：节点内部的多台缓存/源站服务器之间分配请求，常用轮询、加权轮询、最小连接数、一致性哈希等算法。

一致性哈希特别值得一提：它让“同一资源总是落到同一台缓存服务器”，这样某台机器故障或扩容时，只有少量缓存需要重新分布，而不是全部失效（避免“缓存雪崩”）。

3.2 协议优化：HTTP/1.1 → 2 → 3

网页要快，协议是关键。浏览器和 CDN 之间、CDN 和源站之间，都在不断升级协议。

HTTP/1.1 的痛点：队头阻塞

HTTP/1.1 下，同一连接一次只能处理一个请求，多个资源要串行或开多个连接。一个慢请求会“堵住”后面的请求，称为队头阻塞（Head-of-Line Blocking）。

HTTP/2：多路复用

HTTP/2 在同一个 TCP 连接上分出多个“流（Stream）”，可并行交错传输，彻底解决应用层队头阻塞，并支持头部压缩（HPACK）、服务器推送。

HTTP/3 / QUIC：绕开 TCP 的阻塞

HTTP/2 仍跑在 TCP 上，而 TCP 本身也有队头阻塞（一个丢包会阻塞整个连接）。HTTP/3 基于 QUIC 协议，跑在 UDP 之上，把传输与加密合并，实现：

• 0-RTT / 1-RTT 建连：比 TCP+TLS 的多次握手快得多；
• 连接迁移：手机从 Wi-Fi 切到 4G 不掉连接（靠 Connection ID 而非 IP）；
• 独立流：单个流丢包不影响其他流。

3.3 压缩：让数据更“瘦”

传输体积越小，延迟越低、带宽费越省。常见压缩：

3.4 动手试一试：压缩能省多少？

假设一份文本资源原始大小为 X KB，选择压缩算法后观察节省比例。注意：图片/视频用专用编码，文本才用 Gzip/Brotli。

3.5 图片与视频优化

现代网页 60%~80% 的流量来自图片和视频，CDN 在这方面是大头：

• 实时转码与格式转换：同一张图，按设备返回 WebP/AVIF；按屏幕宽度返回合适尺寸（responsive images）。
• 质量自适应：视频根据网络状况动态调整码率（ABR）。
• 分片与就近拉流：直播/点播把流切成小片段（HLS/DASH），边缘节点就近提供，降低首帧时间、减少卡顿。

3.6 边缘计算（Edge Computing）

传统 CDN 只“搬运”内容；现代 CDN 把计算也下沉到边缘。你可以在边缘节点运行自定义代码，做：

• 请求改写、A/B 测试、个性化内容注入；
• 鉴权、风控、Bot 识别；
• 图像实时处理（裁剪、水印）；
• 轻量 API 与 SSR（服务端渲染）。

代表产品：Cloudflare Workers、AWS Lambda@Edge、Akamai EdgeWorkers、阿里云 EdgeRoutine、腾讯云 EO（边缘函数）。这把“离用户近”的优势从“低延迟传输”扩展到“低延迟计算”。

3.7 TLS / HTTPS 优化

• TLS 握手优化：使用 TLS 1.3（1-RTT，支持 0-RTT 恢复）、会话复用（Session Resumption / TLS False Start）。
• OCSP Stapling：由 CDN 在握手时附带证书状态，避免客户端再去证书机构查询。
• 证书自动化：商业 CDN 通常免费提供并自动续期 SSL 证书（如 Let's Encrypt / 厂商自有 CA）。
• 全链路加密：用户↔边缘用 HTTPS，边缘↔源站可配置 HTTPS 或专线回源。

3.8 本章小结

4.1 为什么 CDN 天然适合做安全

CDN 位于用户和源站之间，是所有流量的“统一入口”。这意味着：

• 隐藏源站 IP：攻击者只能看到边缘节点，无法直接打源站；
• 海量带宽与算力：大厂 CDN 拥有 Tbps 级清洗能力，远胜单台源站；
• 全局视野：可基于全网流量识别攻击特征与异常。

所以“上 CDN”几乎是网站安全的第一步。下面是一个典型的“多层防护”结构：

4.2 DDoS 防护

DDoS（分布式拒绝服务）通过海量请求淹没目标，使其无法服务正常用户。CDN 的防护手段：

4.3 WAF（Web 应用防火墙）

WAF 工作在应用层，能识别并拦截 SQL 注入、XSS、路径遍历、恶意扫描等 Web 攻击。CDN 上的 WAF 通常以“规则集 + 托管规则”形式提供：

• 托管规则：厂商维护的常见攻击特征库，开箱即用；
• 自定义规则：按 URI、参数、IP、国家/地区、请求头设白/黑名单；
• 速率限制（Rate Limiting）：对单 IP/用户的请求频率设阈值；
• 模式：观察（仅记录）vs 拦截（直接阻断），上线前建议先观察。

4.4 Bot 管理

互联网流量中相当比例是机器（爬虫、刷单、撞库、薅羊毛）。Bot 管理区分“好 Bot”（搜索引擎）与“坏 Bot”（恶意），手段包括：

• 指纹识别：TLS/JA3 指纹、设备指纹；
• 行为分析：访问节奏、鼠标轨迹、是否真人；
• 挑战机制：CAPTCHA、JavaScript 挑战、Cookie 验证；
• 规则：允许搜索引擎、拦截匿名代理/数据中心 IP。

4.5 防盗链、鉴权与私有内容

• Referer 防盗链：只允许特定来源站点引用资源，防止别人盗用你的图片/视频带宽。
• 签名 URL / 签名 Cookie：对私有内容（如付费视频）生成带过期时间的鉴权链接，过期即失效。
• IP/地区限制：仅允许特定 IP 段或国家访问。

签名 URL 示例（概念）

https://cdn.example.com/video/mp4/lesson01.mp4?
  expire=1770000000&
  sign=3f9a1c...# 由 secret key 对 path+expire 生成的 HMAC

边缘节点用相同算法校验：签名正确且在有效期内才放行，否则返回 403。

4.6 证书与加密管理

• 免费证书：商业 CDN 多提供免费 DV 证书并自动续期（Let's Encrypt 或厂商 CA）。
• 自定义证书：可上传企业 OV/EV 证书。
• 强制 HTTPS / HSTS：自动将 HTTP 跳转 HTTPS，并下发 HSTS 头防止降级攻击。
• 回源加密：边缘到源站可强制 HTTPS，敏感业务建议开启。

4.7 本章小结

5.1 什么时候考虑开源 / 自建

商业 CDN 省心省力，但开源方案在以下场景更有吸引力：

• 成本敏感 + 大流量：当带宽费超过自建机柜/服务器成本时；
• 数据合规 / 私有化：数据不能出内网或特定区域（政企、金融）；
• 极致可控：需要深度定制缓存逻辑、改写规则、边缘脚本；
• 学习与演练：想真正理解 CDN 内部机制。

5.2 Nginx / OpenResty 开源

Nginx 是最常用的 Web 服务器与反向代理，其 proxy_cache 模块即可作为轻量级边缘缓存。生态成熟、性能极高（事件驱动、单机数万并发）。

OpenResty = Nginx + LuaJIT，让你用 Lua 脚本在请求各阶段做任意逻辑（鉴权、改写、限流、灰度），是“边缘计算”思想的早期实践，很多商业 CDN 的管控面也基于它。

proxy_cache_path /data/cache levels=1:2 keys_zone=mycache:10m max_size=10g inactive=60m;
server {
  location / {
    proxy_cache mycache;
    proxy_cache_key $scheme$host$request_uri;
    proxy_cache_valid 200 10m;
    add_header X-Cache-Status $upstream_cache_status;  # HIT/MISS/EXPIRED
    proxy_pass http://origin;
  }
}

5.3 Varnish Cache 开源

Varnish 是专注“HTTP 缓存”的高性能反向代理，用 VCL（Varnish Configuration Language）配置缓存策略，缓存命中率与吞吐极高，是许多大型网站（Wikipedia、社交平台）的缓存核心。它通常放在 Nginx 之前，专门做缓存层。

# default.vcl 片段：设置 TTL 与缓存键
sub vcl_backend_response {
  set beresp.ttl = 1h;
  if (bereq.url ~ "\\.jpg$") { set beresp.ttl = 1d; }
}

5.4 Apache Traffic Server (ATS) 开源

ATS 源自 Yahoo，是一个成熟的大规模缓存代理，支持正向/反向代理、多级缓存、插件化（用 C++ 写插件）。它在超大规模（百万级 QPS）场景表现稳定，是构建“类商业 CDN”时常用的缓存核心。其分层缓存（parent/child）天然适合做区域汇聚层。

5.5 Squid 开源

Squid 是最老牌的代理/缓存软件，常以“正向代理缓存”或内网缓存网关出现。性能与现代化程度不如 Varnish/ATS，但在简单缓存、访问控制场景仍可用。

5.6 Caddy 开源

Caddy 以“默认自动 HTTPS”著称，配置极简（用 Caddyfile），内置现代协议（HTTP/2、实验性 HTTP/3）。适合小团队快速搭一个带缓存与 TLS 的反向代理。其 encode 指令可一键开启 gzip/brotli。

example.com {
  encode zstd gzip
  reverse_proxy localhost:8080
  # 自动申请并续期 Let's Encrypt 证书
}

5.7 HAProxy 开源

HAProxy 是顶级的负载均衡器（L4/L7），本身不做内容缓存，但常作为 CDN 架构里的“流量调度/入口”角色，做健康检查、速率限制、TLS 终止。与 Nginx/Varnish 配合使用。

5.8 Envoy / Traefik 开源

• Envoy：云原生高性能代理，是 Service Mesh（如 Istio）的数据面，支持高级路由、可观测性，适合构建现代化的边缘/网格。
• Traefik：为微服务/容器（Docker/K8s）设计的反向代理，自动服务发现，配置动态。

5.9 jsDelivr：开源 CDN 的典范 开源

jsDelivr 是一个免费、开源的公开 CDN，专注于为 npm、GitHub、WordPress 等提供前端库加速。它的特别之处在于：多 CDN 融合——同时接入 Cloudflare、Fastly、以及各地的运营商节点，并开源了调度逻辑；当某个供应商故障时自动切换。它证明了“开源 + 多供应商”也能做到高可用。

# 直接引用公开库，自动就近加速
<script src="https://cdn.jsdelivr.net/npm/vue@3/dist/vue.global.js"></script>

5.10 自建 CDN：一套参考架构

若决定自建，一个简化但完整的架构通常包含：调度层（GeoDNS/Anycast）→ 边缘缓存层（Nginx+Varnish）→ 区域汇聚层（ATS/Squid）→ 源站。调度层负责把用户导向最近节点，边缘层承接绝大多数命中，未命中向上汇聚回源，从而把回源率压到最低。

5.11 开源组件对比

5.12 本章小结

6.1 商业 CDN 解决了什么

商业 CDN 把“网络、节点、调度、安全、监控”打包成服务。你只需改 DNS 或加一条 CNAME，就能获得：

• 遍布全球的 POP（大厂数千节点）；
• 自动调度、Anycast、HTTP/3、Brotli 等开箱即用；
• 内置 DDoS/WAF/Bot/证书管理；
• 可视化的监控、日志与告警；
• 按量计费，无需自建与运维。

6.2 国际主流厂商

Cloudflare 商业

以“免费 tier + 开发者生态”出圈。免费版即提供 CDN、DNS、基础 DDoS、SSL、WAF 规则、Workers 边缘计算。优势：易上手、全球 Anycast 网络、生态丰富（Pages、R2、Workers、Turnstile 验证）。适合个人、开发者、中小企业，以及重视边缘计算的团队。注意：免费版对特定滥用场景有约束，企业级功能（高级 WAF、Bot 管理、中国节点）需付费。

Akamai 商业

老牌“企业级 CDN 之王”，节点数与企业客户覆盖极广，尤其在金融、媒体、政企领域。产品矩阵庞大（CDN、WAF、Kona Site Defender、EdgeWorkers 等），安全能力行业顶尖。适合对稳定性、合规、安全有极高要求的大型机构，但价格与复杂度也最高。

AWS CloudFront 商业

亚马逊云科技的 CDN，与 S3、EC2、Lambda@Edge、API Gateway 深度集成，配置灵活、按量付费、全球覆盖。Lambda@Edge 与 CloudFront Functions 提供边缘计算。适合已用 AWS 体系、需要细粒度控制与编程能力的团队。

Azure Front Door / Azure CDN 商业

微软云的“全站加速 + 应用交付”服务（Front Door 面向动态加速与全局路由，含 WAF）。与 Azure 服务、Microsoft 365 生态集成好。适合以 Azure 为主、需要统一入口与全球路由的企业。

Google Cloud CDN 商业

基于 Google 全球边缘网络，与 Cloud Storage、Compute Engine、Global Load Balancing 集成，支持 HTTP/3、Cloud Armor（安全）。适合 GCP 用户与对 Google 网络质量有偏好的场景。

6.3 国内主流厂商

由于网络环境与合规要求，国内业务通常需要国内的 CDN 节点（且需 ICP 备案）。

阿里云 CDN / 全站加速 DCDN 商业

国内份额领先，节点多、覆盖广，提供 CDN、全站加速（DCDN，动静混合加速）、视频云、SCDN（安全加速）、边缘节点服务 ENS。与阿里云生态（OSS、ECS）无缝。适合国内各类网站、电商、视频、游戏。

腾讯云 CDN / 边缘安全加速平台 EO 商业

腾讯云提供 CDN、ECDN（全站加速）、以及一体化的边缘安全加速平台（EdgeOne / EO）——把 CDN 加速、DNS、DDoS 防护、WAF、Bot 管理整合到一个平台，对标 Cloudflare。适合需要“加速+安全一体化”的国内/出海业务。

其他国内厂商

• 网宿科技（Wangsu）：老牌 CDN 厂商，企业级客户多，节点与经验丰富。
• 白山云（Baishan）：主打一体化边缘云与数据安全。
• 又拍云 / 七牛云：开发者友好，对象存储 + CDN 组合常见。
• 华为云 CDN：与华为云生态结合，政企项目常见。

6.4 商业 CDN 横向对比

6.5 如何选型

6.6 商业 vs 开源：一张决策图

6.7 本章小结

7.1 接入 CDN 的典型步骤

1. 准备源站：确保源站可公网访问，记录源站 IP/域名、端口、回源协议（HTTP/HTTPS）。
2. 注册并添加域名：在 CDN 控制台添加加速域名（如 cdn.example.com 或把主域名 www.example.com 接入）。
3. 配置源站：填写源站地址、回源 Host、回源协议、端口。
4. 修改 DNS：将域名 CNAME 到 CDN 提供的加速域名（或 NS 托管到 CDN）。
5. 配置缓存与 HTTPS：设置缓存规则、开启 HTTPS 与证书。
6. 验证：用 curl -I 查看响应头是否来自 CDN（如 X-Cache、CF-Cache-Status），确认命中。
7. 灰度与监控：先小流量验证，再全量；接入监控告警。

7.2 静态与动态分离（推荐架构）

最佳实践是把流量按“是否可缓存”拆分：

7.3 缓存规则怎么配

缓存规则有“优先级”，通常按：精确路径 > 文件类型 > 全局默认。示例策略：

# 伪配置：自上而下匹配，先匹配先生效
规则1: 路径 /api/*            → 不缓存（no-cache）
规则2: 后缀 .jpg/.png/.css/.js → 缓存 30 天
规则3: 路径 /news/*           → 缓存 5 分钟
规则4: 全局默认               → 缓存 1 小时

7.4 配置 HTTPS 与证书

• 开启强制 HTTPS：HTTP 请求 301 跳转到 HTTPS。
• 证书：商业 CDN 多提供免费自动证书；也可上传自有证书。
• 回源协议：边缘到源站建议 HTTPS（尤其涉及登录/支付）。
• HSTS：下发 Strict-Transport-Security 头，防止降级攻击（开启前确保全站已支持 HTTPS）。

7.5 全站加速（DCDN / ECDN）

对“动静混合”或“强动态”站点，普通 CDN 对动态部分无能为力。此时用全站加速：

• 对静态部分照常缓存；
• 对动态部分，通过智能路由（选最优链路）、协议优化（TCP/TLS 优化、HTTP/2/3）、连接复用（边缘到源站的长连接池）来提速；
• 本质是“把用户到源站这条长链路，替换成 用户→边缘（短、优）+ 边缘→源站（优化通道）”。

7.6 动手试一试：缓存规则规划器

输入你的资源路径与类型，生成一份示例缓存配置。这只是教学演示，真实控制台操作以厂商 UI 为准。

7.7 上线检查清单

7.8 本章小结

8.1 必须盯紧的核心指标

8.2 命中率与回源率：最重要的两个数字

它们直接反映 CDN 是否“替源站干了活”。一个简单关系：

回源率 = 1 - 命中率（近似）
例：命中率 95% → 回源率约 5%，即 100 个请求只有 5 个打到源站

如果命中率长期偏低（如 <70%），说明缓存策略有问题：TTL 太短、缓存键过细（把无关参数纳入键）、或大量请求带了会变化的参数（如每次不同的追踪 ID），导致“每个请求都像新资源”。

8.3 动手试一试：命中率换算器

8.4 日志与监控怎么做

• 实时面板：厂商控制台通常提供命中率、带宽、QPS、Top URL、状态码分布。
• 原始日志：可下载/投递到对象存储或日志系统（如 ELK、Splunk），做自定义分析。
• 合成监控（RUM + 拨测）：从不同地域主动探测，模拟真实用户体验（首屏、首包）。
• 告警：对命中率骤降、5xx 飙升、回源突增设阈值告警。

8.5 常见调优动作

8.6 一个调优案例

问题：某电商首页 TTFB 高、源站 CPU 高。
排查：日志显示首页命中率仅 40%，因为每次请求都带 ?t=时间戳 导致缓存键不同。
对策：① 在 CDN 配置中忽略 t 参数；② 首页缓存 2 分钟 + 发布时主动刷新；③ 静态资源带 hash 长缓存。
结果：命中率升到 95%，源站 CPU 下降 70%，TTFB 从 320ms 降到 45ms。

8.7 本章小结

9.1 先确认：请求到底有没有走 CDN

排查第一步，永远是先看响应头。用：

curl -I https://example.com/style.css
# 关注：X-Cache / CF-Cache-Status / X-Served-By / Age / Server 等头
# 出现 MISS/EXPIRED 是正常的，HIT 表示命中

如果连 CDN 的特征头都没有，说明 DNS 没指向 CDN（CNAME 没配/未生效），请求直连了源站。

9.2 场景一：访问慢 / 首包时间高

9.3 场景二：内容不更新（改了源站，CDN 还是旧的）

• TTL 未到：缓存还在有效期内，属正常。等过期或主动刷新（purge）。
• 刷新没生效：确认刷新的是正确 URL/目录；带查询参数的 URL 与无参数视为不同资源。
• 缓存键问题：URL 看似一样，实则因参数/大小写/压缩变体不同。
• 最佳实践：静态资源用 hash 文件名，更新即换 URL，彻底避免“清缓存焦虑”。

9.4 场景三：回源失败 / 5xx 错误

9.5 场景四：HTTPS / 证书问题

• 证书不匹配：上传的证书域名与加速域名不一致。
• 混合内容：HTTPS 页里引用了 HTTP 资源，被浏览器拦截 → 统一改 https 或用协议相对 URL。
• 回源证书无效：边缘到源站 HTTPS 时，源站证书需可信（或用自签时关校验——不推荐）。

9.6 场景五：源站 IP 暴露被攻击

即使上了 CDN，如果源站 IP 曾在 DNS、邮件头、Git 历史等地方泄露，攻击者仍可直打源站。对策：

• 源站防火墙仅放行 CDN 回源 IP 段；
• 更换源站 IP（若已泄露）；
• 对源站也启用基础防护；
• 避免在任何公开处暴露真实 IP。

9.7 排查黄金法则

10.1 边缘计算成为主战场

CDN 的节点已不只是“缓存盘”，而是遍布全球的计算单元。开发者把代码部署到边缘，让逻辑在离用户几毫秒的地方运行：个性化、A/B、鉴权、图像实时处理、甚至轻量 API。代表：Cloudflare Workers、AWS Lambda@Edge、Deno Deploy、Fastly Compute、阿里云 EdgeRoutine、腾讯云边缘函数。

10.2 AI 与 CDN 的双向奔赴

• CDN 赋能 AI：大模型推理结果、向量、静态资产通过边缘分发，降低推理服务的冷启动与带宽成本；边缘 AI 推理让简单模型在边缘跑（如图像分类、内容审核）。
• AI 优化 CDN：用机器学习做更精准的调度、预测式缓存（提前把热内容推到边缘）、异常流量识别与自适应限速。

10.3 协议全面迈向 QUIC / HTTP/3

随着移动端与弱网占比提升，HTTP/3 over QUIC 的 0-RTT、连接迁移、无队头阻塞特性价值凸显。未来几年 HTTP/3 将从“可选”变为“默认”，尤其在视频、游戏、移动端。

10.4 安全与加速进一步融合

“加速”和“安全”曾是两套产品，现在正合并为一体化边缘安全加速平台（如 Cloudflare、腾讯云 EO、Akamai 的整合方案）。一个入口同时搞定调度、缓存、DDoS、WAF、Bot、零信任访问。

10.5 Serverless、WebAssembly 与边缘运行时

边缘函数正从“厂商私有运行时”走向标准与可移植：WebAssembly（WASM）让同一份代码跑在任意边缘；WinterCG 等标准推动边缘 API 互通。这意味着你写的边缘逻辑，未来可更少绑定单一厂商。

10.6 绿色与可持续

CDN 能耗随流量增长。行业在通过更高效编码（AV1）、智能调度（减少无效传输）、绿色数据中心与可再生能源来降碳。作为使用者，合理的缓存与压缩配置本身也是在“省能”。

10.7 给学习者的建议

1. 动手比读书重要：开一个免费 Cloudflare 或国内 CDN 试用账号，接一个自己的小站。
2. 读响应头：养成 curl -I 看 X-Cache 的习惯，能看懂 CDN 在做什么。
3. 理解协议：HTTP/2、HTTP/3、TLS 是绕不开的底层知识。
4. 关注边缘计算：这是 CDN 下一阶段的增量价值。
5. 保持好奇：每当你觉得“网速慢/卡”，都试着用 CDN 的视角去解释它。

T1.1 缓存键（Cache Key）规范化

缓存键决定了“哪些请求被视为同一份内容”。默认情况下，URL 中的查询参数往往被纳入键，这会导致严重问题：追踪参数 ?utm_source=xxx、?t=时间戳、?session=yyy 让每个请求都变成“新资源”，命中率暴跌。

对策：忽略无关参数。大多数 CDN 支持配置“缓存键忽略指定查询参数”或“仅保留白名单参数”。例如只保留 ?v= 用于版本控制，忽略其余。

# 伪配置：缓存键只保留 path，忽略所有查询参数
cache_key = $scheme$host$uri          # 不含 $query_string
# 或：忽略utm_*、t、_等追踪参数，保留关键参数

T1.2 Vary 头与内容协商

同一 URL 可能因 Accept-Encoding（gzip/brotli）、User-Agent、Accept-Language 返回不同内容。CDN 用 Vary 头区分这些变体。但 Vary: User-Agent 会让缓存碎片化（每个 UA 一份），通常建议只在编码维度做变体（gzip/brotli），其余在边缘统一处理或忽略。

T1.3 主动刷新（Purge）与优雅过期

• Purge：主动让某 URL/目录/通配符的缓存立即失效。适合发布后强制更新。
• stale-while-revalidate（后台刷新）：缓存过期后，先返回旧内容给用户（保证不卡顿），同时后台异步回源更新。既新鲜又不阻塞。
• stale-if-error：源站故障时，返回旧缓存而非报错，提升可用性。

Cache-Control: public, max-age=300, stale-while-revalidate=60, stale-if-error=86400

T1.4 请求合并（Request Collapsing）

当缓存刚好失效、瞬间涌入 1000 个相同请求，朴素实现会回源 1000 次（“惊群效应”）。请求合并让这 1000 个请求只触发 1 次回源，其余等待并复用结果。

T1.5 分层缓存与回源收敛

单级边缘缓存容量有限，多层结构（边缘 → 区域 → 核心）能把回源收敛到极少数节点，极大降低源站压力。配合回源 Host 统一、回源连接复用（长连接池），进一步减少握手开销。

T1.6 命中率优化的检查清单

上一个专题讲了缓存键、Vary、刷新、请求合并、分层这些“骨架”。这一章把缓存真正**加速**的细节补齐：那些头到底怎么读、缓存满了先扔谁、为什么有时候缓存反而帮倒忙、以及怎么用数字证明你的缓存做得好。

A.1 HTTP 缓存头：一次讲透

CDN 的缓存行为，九成由源站返回的响应头决定。很多“CDN 不生效”“改了不更新”的问题，根源都是这几个头写错了。

Cache-Control 常用指令全表

为什么需要 s-maxage 这个“双份保质期”

浏览器和 CDN 的合适缓存时长常常不一样：

• 浏览器缓存久了很麻烦——用户电脑里那份你没法主动删，只能等它自然过期。
• CDN缓存久了很爽——你随时可以调 Purge 接口把它刷掉。

所以最佳实践是：让 CDN 存久一点，让浏览器存短一点。

# 推荐组合：CDN 存 1 天，浏览器只存 1 小时
Cache-Control: public, max-age=3600, s-maxage=86400

# 带版本指纹的静态资源（文件名会变，内容永不变）：可以给到一年
Cache-Control: public, max-age=31536000, immutable

Expires 与 Age

• Expires：老式写法，写的是一个绝对时间点（如 Thu, 01 Jan 2027 00:00:00 GMT）。缺点是依赖客户端时钟，时钟不准就失效。
• 优先级：同时存在时，Cache-Control: max-age 压过 Expires。
• Age：CDN 返回的响应里带的“这份内容已经在缓存里躺了多少秒”。剩余新鲜度 = max-age − Age。排查时看 Age 很有用：Age 一直是 0，说明每次都在回源。

A.2 强缓存与协商缓存：完整决策链

浏览器或 CDN 拿到一个请求时，脑子里跑的是这样一条链：

ETag 与 Last-Modified 怎么选：

A.3 让用户永远不等待：stale-while-revalidate

传统缓存有个尴尬时刻：内容刚好过期的那一瞬间，来的那个用户特别倒霉——他得等 CDN 回源一趟才能拿到内容。

stale-while-revalidate（RFC 5861，现已并入 RFC 9111）解决了这个问题：

Cache-Control: public, max-age=60, stale-while-revalidate=30, stale-if-error=86400

• stale-while-revalidate=30：过期后 30 秒内，先把旧的立刻给用户（用户零等待），同时后台悄悄回源刷新。下一个用户就拿到新的了。
• stale-if-error=86400：如果回源失败（源站 5xx 或直接挂了），继续拿旧内容顶一天。源站宕机，用户却几乎无感。

A.4 缓存满了先扔谁：淘汰算法

边缘节点的磁盘是有限的。内容装满后，来了新内容就必须扔掉一些旧的——这就是淘汰算法。它直接决定命中率。

“只看一次”的内容，是缓存最大的敌人

这个现象有个专门的名字：one-hit wonder（一次性奇迹）——被访问了一次，然后再也没人碰，却白白占着缓存空间。

它有多严重？S3-FIFO 论文分析了 6594 组生产环境真实访问记录（涵盖 610 亿个对象、8560 亿次请求），结论令人吃惊：

换句话说：在容量吃紧的边缘节点上，可能有七成的缓存空间在为“再也不会有人看第二眼”的内容服务。这也是为什么下一节的“准入”比“淘汰”更值得投入。

A.5 准入策略：决定“什么不该进缓存”

大多数人只想着“缓存满了扔谁”，却忽略了更高杠杆的问题：它一开始就该被存进来吗？

准入策略的效果有多大？AdaptSize 论文在 Akamai 的真实生产数据上做过对比：

原因很直白：大量对象还没等到第二次请求就被挤出去了。不是淘汰算法不够聪明，是不该进来的东西进来得太多。

A.6 穿透、击穿、雪崩：三个容易搞混的事故

这三个词国内面试特别爱问，名字像但完全是三回事。记住区分点：穿透是查不存在的东西，击穿是一个热点过期，雪崩是一大批同时过期。

为什么 TTL 一定要加随机抖动

如果你在一次发布中把 10 万个文件的 TTL 都设成 3600 秒，那么一小时后的同一秒，这 10 万个缓存会一起失效，10 万个回源请求同时砸向源站。

解决办法极其简单，就是给过期时间加一点随机：

# 不要这样（所有 key 同一秒过期）
TTL = 3600

# 要这样：基础值 + 随机抖动，把失效时刻打散到 1 小时区间内
TTL = 3600 + random(0, 3600 * jitter)
# jitter 工程上常取 10% ~ 30%

A.7 切片缓存（Slice）：大文件的正确姿势

一个 2GB 的安装包或电影文件，如果不做切片直接缓存，会遇到四个问题：

• 用户只想看中间一段，CDN 却要把整个 2GB 都回源拉回来——首字节等到花儿都谢了；
• 单个缓存对象太大，管理和淘汰都很笨重；
• 无法部分命中：拉了 99% 中断，下次还得重来；
• 用户拖动进度条（seek）时，体验极差。

切片缓存把大文件按固定大小（常见 1MB / 4MB）切成小块，每块独立缓存、独立命中。用户请求哪一段，CDN 就只回源拉那一段。

Nginx 真实可用配置

需要编译时带上 --with-http_slice_module：

location / {
    slice 1m;                                        # 每片 1MB
    proxy_cache my_cache;
    proxy_cache_key $uri$is_args$args$slice_range;   # 关键：切片区间必须进缓存键
    proxy_set_header Range $slice_range;             # 把区间作为 Range 发给源站
    proxy_cache_valid 200 206 1h;                    # 206 也要缓存！
    proxy_http_version 1.1;
    proxy_pass http://origin;
}

切片大小怎么选：

Nginx 默认建议 1m，工程上常用 1MB ~ 4MB。

A.8 缓存预热：别让第一批用户当小白鼠

新节点、新版本、大促、热剧上线时，边缘节点的缓存是空的。第一批涌入的用户会全部未命中，把回源流量瞬间放大几十倍——源站可能就这样被自己的用户打挂了。

预热和刷新（Purge）是反向操作，别搞混：

• 工程做法：调 CDN 的预热 API 批量提交 URL 列表；按历史热度预测该预热什么；灰度预热（先推一部分节点验证无误，再全量）。
• 要注意：预热风暴——一次提交几十万个 URL，等于自己对源站发起一次 DDoS。务必限速、分批。
• 预热完要校验命中（抽查几个 URL 看 X-Cache 是否为 HIT），别以为提交了就成功了。
• 不要预热低价值内容，否则只是白占缓存、挤掉真正的热点。

A.9 命中率量化：用数字证明你做得好

命中率有两个，很多人只看一个，于是被误导。

定量关系（可以直接用来估成本）：

回源流量 = (1 − 字节命中率) × 边缘总流量
源站需承担的带宽 ≈ (1 − 字节命中率) × 峰值带宽
回源成本节省比例 ≈ 字节命中率

合理目标值参考：

命中率杀手清单（逐条自查）

• 源站下发了 no-store / private / Set-Cookie，CDN 直接放弃缓存；
• TTL 设得过短（几十秒），刚存下就过期；
• URL 带随机参数（时间戳、追踪码、鉴权 token）没忽略，同一份内容被拆成无数份缓存；
• 文件名没有版本指纹，每次发布只能全量 Purge，缓存反复清空；
• 大文件没开切片和 Range 回源；
• Vary 头过于宽泛（比如 Vary: User-Agent），缓存被拆成成百上千份；
• 流量太分散，长尾内容在节点上根本攒不够热度（详见短视频专题）。

A.10 边缘节点内部的三级存储

一个 CDN 节点里，缓存并不是放在一种介质上，而是分三层：

A.11 缓存之外：还有这些提速手段

命中率拉满之后，剩下的时间花在哪？花在连接上。

视频是 CDN 最大的战场，也是最考验缓存功力的场景。这一章从“视频文件长什么样”一路讲到“为什么你的视频命中率只有 30%”。

T2.1 为什么视频是 CDN 的“主战场”

视频流量占全球互联网流量的大头。一段 1080p 视频每分钟可能几十 MB，若每个观众都直连源站，源站与带宽瞬间被击穿。CDN 通过就近分发分片，让百万观众从边缘获取内容。

视频与普通网页资源相比，有三个“难搞”的特性：

• 体积大：单个文件动辄几百 MB 到几 GB，字节命中率直接决定账单；
• 不是一次读完：用户会暂停、拖动、切码率，访问模式是碎片化的；
• 一份内容存多份：为了适配不同网速和终端，同一个视频要转出多档码率、多种封装——存储和缓存成本成倍放大。

T2.2 三种封装格式：HLS、DASH、CMAF

现代流媒体不再是“一个大文件从头下到尾”，而是把视频切成几秒一段的分片，再用一个清单文件告诉播放器“按什么顺序播”。

T2.3 分片切多长？一个四方权衡

分片时长是流媒体最基础也最容易设错的参数。它同时影响四件事，而且方向是相反的：

LL-HLS：把“等一整片”变成“等一小片”

低延迟 HLS（LL-HLS）是 Apple 的官方低延迟方案，靠三个机制把延迟压下来：

• EXT-X-PART（部分分片）：把一个 6 秒的父分片再切成约 200 毫秒 的小片，父片还没生成完就可以先发小片。
  为什么：发货不用等装满一整车，装满一个小箱就发走。
• EXT-X-PRELOAD-HINT（预加载提示）：清单里提前预告“下一个小片的地址是这个”，播放器可以提前把请求发出去，省掉一次往返。
  为什么：提前下单，货一到就取走。
• 阻塞式清单刷新：播放器带上 _HLS_msn / _HLS_part 参数请求清单，服务器先挂住不回，等目标分片就绪才返回——取代了低效的反复轮询。
  为什么：不用一直刷新页面，好了自动给你。

T2.4 自适应码率（ABR）：网速变了画质跟着变

自适应码率是指同一个视频提供多档清晰度，播放器边播边测网速，动态切换：网好升画质，网差降码率保流畅。

主流 ABR 算法

码率阶梯（bitrate ladder）怎么排

相邻两档的码率不能太近（浪费）也不能太远（切换时画质突变太明显）。Apple 的规范建议相邻档位大约 1.5 倍的间隔，工程上常用 1.4~1.7 倍。一组常见的 H.264 参考值：

Per-Title Encoding：不要一刀切

传统做法是所有视频用同一套码率阶梯。但动画片和体育赛事的复杂度天差地别——给动画片配体育赛事的码率纯属浪费。

Per-Title Encoding（逐片源编码 / 内容自适应编码）就是按每个视频的实际复杂度定制码率阶梯。Netflix 在 2015 年公开的数据是：平均可省约 20% 带宽（业界常引用的区间是 20%~40%），画质持平或更好。更进一步的 per-shot（逐镜头）编码还能再省 10%~15%。

T2.5 编码格式选型：H.264 / H.265 / AV1 / VVC

换更先进的编码格式，是最直接的省带宽手段——但代价是算力和兼容性。下表是同等画质下相对 H.264 的码率节省（学术测评数据）：

T2.6 视频缓存的核心：清单和分片必须分开管

清单文件（.m3u8 / .mpd）和分片文件（.ts / .m4s）性质完全不同：

# 清单：短缓存，保证更新及时
location ~* \.(m3u8|mpd)$ {
    add_header Cache-Control "public, max-age=2";
}

# 分片：长缓存，内容不可变
location ~* \.(ts|m4s|mp4)$ {
    add_header Cache-Control "public, max-age=2592000, immutable";
}

鉴权 token 如何毁掉你的命中率

这是视频 CDN 最高频的命中率事故。假设你的视频地址长这样：

https://cdn.example.com/video/ep01/seg_001.ts?token=a1b2c3&t=1735689600

每个用户拿到的 token 和时间戳都不一样。如果 CDN 默认把完整 query 参数纳入缓存键，那么：

正确做法：

• 在 CDN 上开启「忽略 URL 参数」，或配置白名单只保留真正影响内容的参数（比如清晰度 definition）；
• 把 token 只用于访问控制，让边缘节点在校验完 token 之后、按不含 token 的缓存键去查缓存；
• 如果鉴权逻辑复杂，用边缘函数（Edge Function）在边缘完成校验，校验通过再取缓存。

T2.7 切片缓存与 Range 回源（点播视角）

缓存进阶专题的 A.7 讲了切片缓存的通用原理，这里说说它对视频的特殊意义：

• MP4 直接播放（渐进式下载）：如果你不用 HLS/DASH，而是直接放一个大 MP4，那么切片缓存 + Range 回源就是唯一能让拖动流畅的方案；
• 只拉需要的部分：用户从第 10 分钟开始看，边缘只回源拉对应字节区间，不必把整个文件搬过来；
• 断点续传：网络中断后从上次位置继续，已缓存的切片依然命中；
• 206 必须缓存：切片回源返回的是 206 Partial Content，配置里漏了 206 就等于没开缓存。

T2.8 秒开：首帧时间到底花在哪

用户点了播放按钮到看见第一帧画面，这段时间叫首帧时间。它是视频体验的第一道生死线。把它拆开看：

MP4 的 moov box 前置：一个改一行就见效的优化

MP4 文件里有个叫 moov 的“索引表”，播放器必须先读到它才知道音视频数据怎么解析。问题是：默认情况下，很多转码工具会把 moov 放在文件末尾。

后果很严重：播放器先下载文件开头，发现没有 moov，只好再发一个请求跳到文件尾部去取，白白多了一次往返——首帧时间直接多几百毫秒。

# 一行命令把 moov 移到文件开头
ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4

其他实测有效的秒开手段

• 硬解初始化与文件头解析并行：不要串行等待，公开的工程复盘中平均可省 80~120ms；
• 解码器复用：上一个视频的解码器实例直接给下一个视频用，省 40ms 以上；
• 调低起播缓冲水位：默认可能要缓冲 10 帧才起播，降到 5 帧可省数百毫秒（代价是弱网卡顿率略升）；
• HTTP/2 多路复用：清单和分片共用一条连接，省掉重复握手；
• HTTP/3 / QUIC：0-RTT 握手，弱网下首屏提升尤其明显；
• 边缘预热：新剧上线前把前几个分片和清单推到边缘，第一个用户就命中。

T2.9 拖动进度条（seek）优化

用户拖动进度条，本质上是要求“立刻从任意位置开始播”。做得不好会转圈好几秒。关键手段：

• 切片缓存：只拉目标位置那一小块，而不是从头下载（见 T2.7）；
• 关键帧对齐：只能从关键帧（IDR）开始解码，所以关键帧间隔越大，拖动后要等的时间越长；
• seek 到最近关键帧而非精确帧：牺牲一点精度换取即时响应，大多数用户感知不到；
• 处理 EXT-X-DISCONTINUITY：清单里有断点标记时（比如插了广告），要正确处理时间戳跳变，否则会黑屏。

T2.10 防盗链、鉴权与版权保护

视频是高价值内容，被盗刷会直接变成账单。防护是分层的，从便宜到贵：

T2.11 大文件下载加速

• Range 分片回源：用户只下第 100~200MB 时，边缘只回源对应区间，支持断点续传，避免整文件回源。
• 多节点并行：把大文件分片放到不同边缘，客户端并行拉取再拼接。
• 预热式“分发”：发布前把安装包、游戏补丁主动推到边缘（push），上线即满命中。
• 限速与配额：下载类业务容易被刷，配合单连接限速、单 IP 并发限制、签名 URL 控制成本。

T2.12 P2P 与 CDN 混合

在超大并发场景（如热门赛事直播、游戏更新），纯 CDN 成本极高。业界常用 P2P + CDN 混合：相邻观众之间互传分片，CDN 只补“种子”。公开的实测案例显示带宽可省 50%~75%（具体取决于内容热度与观众密度）。

代价要看清楚：首屏可能变慢（要先建 P2P 连接）、NAT 穿透成功率问题、占用用户上行带宽引发的隐私与口碑争议。详见下一章直播专题。

点播的内容是“早就做好的”，直播的内容是“正在生产的”。这一个字的差别，让直播成为 CDN 里最难的一类业务：不能提前预热、所有人都要最新的那一片、还要跟延迟赛跑。

B.1 一场直播的完整链路与耗时预算

先建立全局认知。一场直播从主播到观众要走这么多跳：

B.2 推流协议：主播这一端怎么传

B.3 分发协议与延迟：观众这一端怎么收

CMAF 分块传输：延迟和分片时长“解耦”

这是低延迟直播最优雅的技术，值得单独讲清楚。

传统的问题：HLS 必须等一个分片完整生成才能发布。分片 6 秒，延迟至少 6 秒起步。想降延迟就得把分片切小，但分片切小又导致请求数暴增、编码效率下降、缓存条目爆炸。这是一个死结。

CMAF 分块传输（Chunked Transfer Encoding）怎么解开这个死结：

• 在分片（segment）内部再切成更小的 chunk，每个 chunk 只含 1~15 帧（30fps 下约 33~500 毫秒）；
• 编码器用 HTTP 的 chunked 分块传输，把每个 chunk 一生成就立刻推出去，不等整个分片写完；
• 播放器从“最新的、包含关键帧的 chunk”开始播，延迟可以降到远小于一个分片时长；
• 关键点：CDN 边缘会把流经的 chunk 拼成一个完整分片正常缓存——所以老播放器和普通 CDN 依然能用，向后兼容。

B.4 首屏秒开的核心武器：GOP 缓存

先解释一个前提：视频压缩后，只有关键帧（I 帧 / IDR 帧）能独立解码，其他帧都要依赖前面的帧。从一个关键帧到下一个关键帧之间的这一组画面，叫一个 GOP（Group of Pictures）。

问题来了：一个新观众在任意时刻进入直播间，如果他刚好错过关键帧，播放器就必须干等到下一个关键帧才能出画面。GOP 设 4 秒，最坏情况要黑屏等近 4 秒。

GOP 缓存的解法：让边缘节点始终缓存最近 1~2 个 GOP。新观众一连上来，边缘立刻把缓存的关键帧推给他，瞬间出画面——不用等。

GOP 时长怎么设：

主流云厂商的建议是把直播 GOP 设为 1~2 秒，并在边缘开启 GOP 缓存。

B.5 秒开与低延迟：一对天生的矛盾

这是直播调优最核心的取舍，很多人没想清楚就乱调参数。

工程上的平衡方案：GOP 设 1~2 秒 + 边缘缓存 1~2 个 GOP + 播放器缓冲水位动态调节（网好就压低缓冲降延迟，网差就抬高缓冲保流畅）。

此外还有几个实用手段：

• 音频先行：先把声音放出来，画面稍后跟上。用户对“有声音”的容忍度远高于“完全静默黑屏”；
• 快速启播降码率：先拉最低档快速起播，播起来之后再升到高清；
• 追帧 / 倍速追赶：当播放位置落后直播前沿太多时，用 1.1~1.3 倍速悄悄追上去，或直接丢掉非参考帧；
• 预渲染：提前解码并渲染第一帧，替代静态封面图。

B.6 弱网卡顿治理

卡顿率怎么度量：常用两个定义——卡顿时长占比（卡顿总时长 ÷ 播放总时长）和卡顿次数（每千次播放的卡顿次数）。两个都要看，因为“卡一次 10 秒”和“卡 20 次各 0.5 秒”体验完全不同。

B.7 直播的回源收敛：和点播本质不同

这个差异带来的后果很直接：

• 点播的内容可以预热、可以长缓存，命中率天然高；
• 直播的最新分片刚生成，谁都没有。如果有一万个边缘节点同时发现自己没有这一片，它们会同时回源——源站瞬间被一万个请求打穿。

两道防线：

1. 请求合并（回源收敛）：同一个边缘节点上，成千上万个观众请求同一个最新分片时，只允许一个请求回源，其余的等这一个的结果。这是直播场景下请求合并的价值所在——比点播更关键。
2. 分层回源：边缘 → 中间层 → 源站。上万个边缘节点先汇聚到几十个中间层节点，中间层再回源站。这样源站看到的并发从“上万”降到“几十”。

# SRS 边缘节点回源配置示意
vhost live.example.com {
    cluster {
        mode        remote;
        origin      mid-tier-1:1935 mid-tier-2:1935;   # 指向中间层，不是源站
    }
}

公开的实践复盘显示，合理的边缘 + 中间层架构可以让 70% 以上的请求在边缘被消化，回源带宽成本下降 40%~60%。

B.8 千万级大型赛事：架构与预案

世界杯、春晚这类量级的直播，是 CDN 能力的终极考试。先算一道账：

架构要点：

• 多 CDN 并行 + 实时分流：按厂商实时质量与余量动态调整流量比例，任一家出问题立刻切走；
• 分层回源收敛：边缘 → 中间层 → 源站，绝不允许边缘直连源站；
• 提前扩容与压测：赛前按峰值 1.5 倍准备容量，并做全链路压测；
• 提前预热：把清单文件、播放页静态资源、兜底页全部预推到边缘。

兜底预案（必须提前演练，不能临场想）：

B.9 P2P 分担：省钱但有代价

直播的特点是“同一时刻大量观众要同一份数据”——这恰好是 P2P 最理想的场景。

公开实测数据：某教育直播平台（10 万+ 并发量级，480P / 800kbps）实测，开启 P2P 后带宽消耗降至不开启时的 约 1/4，即节省约 75%，平均延迟约 1 秒。多家厂商公开的节省区间集中在 50%~75%，取决于内容热度和观众地理密度。

原理：把流按分片编号，观众节点之间互相交换自己已有的分片；CDN 只负责补齐那些 P2P 网络里凑不齐的部分（相当于“种子”）。通常配合 push（主动推）+ pull（主动拉）+ 补偿（兜底从 CDN 拉）三段式策略。

另一条路：运营商组播。IPTV 场景下可以用 IGMP 组播，一份数据在运营商内网复制分发，效率极高。但公网 CDN 用不了组播——这是它只在电信 IPTV 生态里流行的原因。

B.10 转码与窄带高清

为什么直播必须转码：主播推上来的是一路流，但观众的设备和网速千差万别。要支持自适应码率，就必须在服务端转出多档。

窄带高清类技术（各厂名称不同，本质是内容自适应编码 + 画质增强）：通过逐场景分析、感知编码等手段，在同等主观画质下把码率降下来。阿里云官方口径是相对普通转码降码率 20%~40%，业界共识区间也在这个范围。

成本权衡（这笔账要自己算）：

短视频是当今最大的 CDN 流量场景，也是一个被很多教材忽略的独特技术领域。它看起来只是“很短的点播视频”，但在 CDN 层面，它几乎每一条规则都和长视频相反。

C.1 短视频和长视频，到底哪里不一样

先看真实的文件规格差异（来自公开的工程复盘对比）：

再看五个本质差异，以及每一个给 CDN 带来的麻烦：

C.2 长尾困境：为什么短视频的命中率天然很低

短视频的访问分布是典型的极端长尾：把所有视频按播放量排序，前面极少数爆款占据了绝大部分流量，后面拖着一条极长的尾巴——那些只被播放过几次甚至一次的视频。

问题在于：这些长尾视频一旦被请求，CDN 就会把它缓存下来，然后它再也不会被访问，白白占着空间，还挤掉了真正的热点。这就是缓存进阶专题 A.4 讲过的 one-hit wonder，而短视频是它最严重的重灾区。

回顾那组学术数据（6594 组生产环境真实访问记录，610 亿对象、8560 亿请求）：

怎么办：把“准入”做起来

C.3 首帧秒开：短视频的生命线

短视频的用户行为是“不好看就立刻划走”。一个视频只有 15 秒，如果起播要花 1 秒，那就是 7% 的内容时间被浪费在等待上——用户根本不会等。

公开的工程复盘给出了一组很有说服力的拐点分析：

所以业界的目标线很明确：首帧压到 200ms 以内，优秀水平是 100ms 以内。某头部平台公开数据显示其核心业务已有 50% 的播放首帧低于 100ms。

四段拆解与对应优化

再强调一次 moov 前置

ffmpeg -i in.mp4 -c copy -movflags +faststart out.mp4

C.4 Feed 流预加载：短视频最独特的技术

这是短视频区别于所有其他视频业务的核心技术。逻辑很简单：用户还在看第 N 个视频时，就悄悄把第 N+1、N+2 个下载好。等他一划，视频已经在本地了，真正做到零等待。

但这里有一个残酷的权衡：

四个关键参数怎么定

三个进阶技巧

• 双播放器（空间换时间）：当前视频起播后，立刻预初始化下一个播放器实例并准备好首帧。公开复盘中，这一招让 200ms 秒播率提升了约 178%；
• 闲时预加载：当用户在某个视频上停留超过 5 秒（说明他在认真看，当前带宽有余量），串行预加载后续内容。有数据显示大盘约 1/3 的播放是重复播放，这类用户的带宽余量更充足；
• 起播优先，预加载让路：当前视频还没起播时暂停所有预加载任务，把带宽全让给当前视频。这一点很关键——预加载抢了当前视频的带宽，就是本末倒置。

C.5 海量小文件：CDN 的隐形负担

短视频文件只有几 MB，但数量是天文级的。“小而多”对 CDN 的伤害常被低估：

应对手段：小文件合并存储（把多个小对象聚合成大块）、边缘内存/SSD 分层（热的小文件直接放内存，避免磁盘 IO）、用 KV 存储专门承载元数据、以及最重要的——连接复用（HTTP/2、HTTP/3 让多个小文件共享一条连接，摊薄握手成本）。

C.6 成本优化：短视频平台的头号课题

短视频平台的 CDN 账单通常是技术支出里最大的一块（有第三方分析称头部平台 CDN 支出可占运营成本的两成左右）。降本手段按性价比排序：

C.7 上传加速：CDN 也要做“写”

这是短视频与传统 CDN 场景的一个重要区别。传统 CDN 只管读加速（把内容分发给用户），但短视频平台有巨量的 UGC 上传流量——几千万创作者往上传视频，上行链路同样需要加速。

C.8 大厂公开实践速览

T3.1 为什么要“多 CDN”

• 避免单点：某家 CDN 故障/被攻击时，流量切换到另一家。
• 覆盖互补：不同厂商在不同地区节点质量不同，按地域择优。
• 成本优化：用竞价/分层策略，把贵流量导到便宜厂商。
• 谈判筹码：多供应商带来议价能力。

T3.2 常见多 CDN 模式

T3.3 调度的实现方式

• DNS 层：用支持健康检查的智能 DNS，按地域/可用性原则返回不同 CNAME。
• HTTPDNS / 客户端：App 内置调度 SDK，按实时探测选最优域名。
• Anycast + BGP：单 IP 多厂商（如 jsDelivr 模式），由网络层自动选路。

T3.4 自建 + 商业的混合

很多团队采用“商业 CDN 为主 + 源站前自建 Nginx/Varnish 缓存”的混合：商业 CDN 负责全球加速，自建层兜底并做精细缓存/改写，既降成本又增可控性。还有的用商业 CDN 扛峰值，自建层扛日常，形成弹性组合。

T3.5 多 CDN 的代价

T4.1 带宽与并发的粗略估算

一个常用估算：

峰值带宽(bps) ≈ 平均单文件大小 × 峰值QPS × 8
例：单文件 500KB，峰值 1000 QPS
   = 500×1024×8 × 1000 ≈ 4.1 Gbps

其中峰值往往是平均的数倍（突发、热点）。CDN 的价值之一正是用边缘弹性吸收这种峰值，避免源站按峰值扩容。

T4.2 命中率如何直接决定成本

假设源站出流量单价为商业 CDN 边缘单价的若干倍（或你的带宽成本），则：

源站承担的流量 ≈ 总流量 × (1 - 命中率)
命中率 50% → 一半流量回源
命中率 95% → 仅 5% 回源

把命中率从 80% 提到 95%，源站/回源流量降为原来的 1/4。这就是为什么前面反复强调缓存键与 TTL。

T4.3 SLA 与可用性数学

多 CDN / 多节点能显著提升整体可用性：单家 99.9% 时，两家独立互备理论上可将不可用时长再降一个数量级（但不完全独立时收益递减）。

T4.4 计费模型一览

T4.5 容量规划清单

1. 估算峰值 QPS 与带宽（考虑热点倍数）；
2. 定目标命中率，反推源站需扛的回源量；
3. 按业务地域映射节点覆盖需求；
4. 预留安全冗余（DDoS 时的突发带宽）；
5. 设监控告警与自动扩容/切换。

案例 1：首页改了却不见更新

现象：运营改了首页 banner，刷新还是旧的。
定位：curl -I 显示 Age: 180、X-Cache: HIT，说明还在缓存期内（TTL 5 分钟）。
解决：主动 purge 该 URL；长期改为带 hash 的资源 + 短缓存 HTML + 发布即刷新。

案例 2：部分地区特别慢

现象：华北快、华南慢。
定位：拨测发现华南解析到的节点异常或跨网。
解决：联系厂商优化调度，或将该区域切到覆盖更好的厂商/节点；启用 HTTP/3 改善弱网。

案例 3：源站 CPU 飙高

现象：CDN 接入后源站 CPU 仍高。
定位：命中率仅 60%，大量回源。
解决：发现 URL 带 ?_=时间戳 导致键碎片化；配置忽略该参数后命中率升到 96%，CPU 回落。

案例 4：被刷流量产生天价账单

现象：某夜流量暴涨，账单异常。
定位：图片被盗链到外部站点，疯狂拉取。
解决：开启 Referer 防盗链 + IP 限速 + 签名 URL；后续对热门资源设更激进缓存。

案例 5：HTTPS 混合内容报错

现象：开启强制 HTTPS 后页面样式丢失。
定位：HTML 里 CSS/JS 用了 http:// 绝对路径。
解决：改为 https:// 或协议相对 //；用脚本批量替换。

案例 6：回源 502，但源站本地访问正常

现象：用户经 CDN 报 502，直连源站正常。
定位：源站防火墙把 CDN 回源 IP 误拦。
解决：在厂商文档查最新回源 IP 段并加白；改用固定回源 IP 或专用回源通道。

T6.1 先认识 Web Vitals

Google 的 Core Web Vitals 是衡量体验的关键指标，CDN 能直接影响它们：

T6.2 关键渲染路径与 CDN 的位置

浏览器从输入 URL 到看到内容，经历：DNS → 建立连接 → 下载 HTML → 下载 CSS/JS → 渲染。CDN 在每一步都能插手：DNS 就近、连接复用（HTTP/2/3）、资源缓存、边缘渲染。

T6.3 预连接与预加载

通过资源提示（Resource Hints）提前建立连接或加载关键资源：

<link rel="dns-prefetch" href="//cdn.example.com">   <!-- 提前解析 CDN 域名 -->
<link rel="preconnect" href="https://cdn.example.com"> <!-- 提前建连（TCP+TLS）-->
<link rel="preload" as="image" href="/hero.avif">      <!-- 预加载首屏大图 -->

注意：preconnect 和 preload 是“双刃剑”——用错（预加载了不重要的资源）反而会拖慢。只给首屏关键资源用。

T6.4 域名分片 vs 合并：时代的转变

HTTP/1.1 时代，为绕过“每域名 6 个并发连接”限制，常把资源分散到多个域名（sharding）。但 HTTP/2 多路复用让单连接即可并行，多个域名反而增加 DNS/握手开销。结论：用 HTTP/2/3 时，合并到单一 CDN 域名通常更优。

T6.5 资源优化清单（与 CDN 配合）

T7.1 常见 Web 攻击与 CDN 防护点

T7.2 WAF 自定义规则示例（概念）

# 伪规则：拦截包含 SQL 注入特征的请求
IF (request.uri CONTAINS "union" AND request.uri CONTAINS "select")
   OR (request.args CONTAINS "0x...")  # 十六进制注入特征
THEN action = block, log = true

# 速率限制：单 IP 每秒 > 50 请求则挑战
IF (client.ip REQUEST_RATE > 50/s) THEN action = challenge

T7.3 速率限制与“挑战”机制

• 速率限制：对单 IP/用户/API Key 设单位时间请求上限，防刷、防爬、防滥用。
• JS 挑战：返回一段 JS，真实浏览器能执行后拿到令牌继续访问，Bot（尤其简单脚本）通常被拦。
• 交互挑战（CAPTCHA）：可疑流量要求手动验证，平衡安全与体验。
• 托管规则集：厂商维护的 OWASP Top 10 等规则，开箱即用，记得定期更新。

T7.4 零信任与 SASE：CDN 的新角色

现代安全趋势是把 CDN 作为零信任访问的边缘：在边缘做身份认证、设备校验、最小权限访问控制，再放行到内部应用。Cloudflare Access、Akamai EAA、Zscaler 等即此类。CDN 从“加速+防护”进一步变成“访问入口与控制平面”。

T7.5 证书与加密的进阶

• mTLS（双向 TLS）：边缘与源站互相验证证书，防止伪造回源。
• 证书透明度（CT）：监控是否有未授权的证书签发。
• OCSP Stapling / CRL：加速证书状态校验、避免隐私泄露。
• 密钥轮换：定期更换签名密钥，降低泄露风险。

T8.1 选型评分维度

把“感觉”变成“打分”。给每个候选按 1~5 分评估，加权求和：

T8.2 国内业务的特殊项：ICP 备案

T8.3 从零迁移到 CDN 的步骤

1. 影子模式：先接入一个测试子域名（如 static.example.com），验证缓存与安全行为，不影响主站。
2. 切静态资源：先把图片/CSS/JS 等静态域名切到 CDN，观察命中率与错误率。
3. 灰度主站：小比例流量（如 5%）切到 CDN，监控 24~48 小时。
4. 全量 + 隐藏源站：确认稳定后全量；将源站改为仅允许 CDN 回源 IP。
5. 收尾：配置监控告警、刷新接口、回滚预案。

T8.4 回滚与应急预案

• DNS 回滚：把 CNAME 切回源站直连（或备 CDN），是最快的“一键回退”。
• 配置版本化：缓存规则、WAF 规则纳入版本管理，出错可回退。
• 多 CDN 互备：如前所述，主备切换在厂商故障时保命。
• 刷新预案：发布后若出问题，能快速 purge 并回滚源站。

T8.5 一份简易选型对照（再强调）

T9.1 TCP 三次握手：连接的“开门三下”

在传任何数据前，TCP 要先建立可靠连接，需三次往返：

客户端 → 服务端：SYN（我想建立连接）
服务端 → 客户端：SYN+ACK（同意，并确认）
客户端 → 服务端：ACK（确认，开始传数据）

这三次交互各消耗一个 RTT（往返时间）。如果客户端到服务端跨大洋，每次 RTT 上百毫秒，三次握手本身就几百毫秒——而 CDN 把“服务端”搬到离你几毫秒的地方，握手时间随之骤降。

T9.2 TLS 握手：HTTPS 的安全开销

HTTPS 在 TCP 之上还要做 TLS 握手来协商密钥：

CDN 普遍支持 TLS 1.3 与会话复用（Session Resumption / 0-RTT 恢复），让“后续连接”几乎零握手开销。同时边缘节点离用户近，哪怕握手多 1 个 RTT 也只多几毫秒。

T9.3 DNS 解析全过程

1. 浏览器查本地缓存，没有则问递归 DNS（Local DNS）。
2. 递归 DNS 问根 → 顶级域（.com） → 权威 DNS。
3. 权威 DNS（CDN 的 GSLB）根据请求者 IP 返回最优边缘节点 IP。
4. 递归 DNS 把结果缓存一段时间后返回给浏览器。

这就是为什么“DNS 缓存”会让调度变更延迟生效——TTL 没过期前，用户可能仍解析到旧节点。这也是 HTTPDNS 直接查询、绕过 Local DNS 缓存的价值所在。

T9.4 HTTP/2 的帧与多路复用（再深入）

HTTP/2 把消息拆成二进制帧（Frame），多个流的帧可以交错在同一个 TCP 连接上传输，接收端再按流重组。这避免了 HTTP/1.1 的队头阻塞（应用层），但TCP 层仍有队头阻塞——一个丢包会阻塞整个连接的所有流，这正是 HTTP/3/QUIC 要解决的根本问题。

T9.5 用工具“看见”CDN

学习时强烈建议亲手看一眼：

# 看响应头，判断是否命中 CDN 缓存
curl -I https://example.com/static/app.js
# 看解析到的 IP 归属（结合 ipinfo 等）
dig +short example.com
# 看各阶段耗时（TCP/TLS/首包）
curl -w "tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n" -o /dev/null -s https://example.com/

对比“直连源站”和“经 CDN”的 time_connect 与 time_starttransfer，你会直观看到 CDN 省下的就是这些握手与传输时间。

T10.1 动态 API 不能直接“缓存”，但能“提速”

API 通常带用户态、实时数据，无法像静态文件那样长期缓存。但 CDN 仍能通过全站加速（DCDN）显著提速：

• 连接复用：边缘与源站之间维护长连接池，省去每次请求的 TCP/TLS 握手。
• 智能选路：边缘到源站走 CDN 内部优化链路，绕开公网拥堵。
• 协议优化：边缘与用户间用 HTTP/2/3，减少握手与队头阻塞。

效果：把一个“用户→源站直连 300ms”的接口，变成“用户→边缘 30ms + 边缘→源站优化通道 60ms”，整体明显下降。

T10.2 缓存 API 响应的正确姿势

部分 API（如公开榜单、配置、字典）是可以缓存的，但要注意：

T10.3 WebSocket 经 CDN

WebSocket 是长连接、双向通信，传统代理支持有限。现代 CDN 多支持WebSocket 加速/终止：

• 边缘终止：用户↔边缘走优化链路，边缘↔源站再用内网/长连接转发，降低源站连接压力。
• 就近接入：用户连最近边缘，减少长连接的握手与抖动。
• 连接收敛：大量客户端连接收敛到少量到源站的连接。

适用场景：聊天、实时协作、行情推送、游戏同步。

T10.4 gRPC、GraphQL 与边缘 BFF

• gRPC-Web / gRPC 代理：部分 CDN/边缘支持 gRPC 转发与负载均衡，适合微服务间高效通信经过边缘的场景。
• GraphQL：CDN 可做查询的持久化与缓存（按查询体做缓存键），并把复杂聚合下推到边缘函数。
• 边缘 BFF（Backend For Frontend）：用边缘函数做接口聚合/裁剪，前端只和边缘打交道，源站只管核心逻辑。这正是“边缘计算 + API 加速”的结合点。

T10.5 实时通信加速的取舍

T11.1 电商与大促（如双 11）

• 动静分离：商品图片/详情页静态化并长缓存，购物车/下单走全站加速。
• 弹性预热：大促前把会场页、海报主动推到边缘（push），开场即满命中，避免瞬时回源雪崩。
• 防刷与风控：抢购接口加速率限制、Bot 管理、签名校验，防黄牛与羊毛党。
• 容灾：多 CDN 互备，避免单点故障导致无法下单。

T11.2 视频、短视频与直播

• 点播：HLS/DASH 分片 + 多码率自适应，弱网自动降码率。
• 短视频：首帧优化（预加载、边缘转封装）、滑动预取。
• 直播：低延迟方案（LL-HLS / WebRTC）、边缘转推与就近拉流，保障赛事/发布会不卡顿。

T11.3 游戏

• 补丁与资源分发：版本更新包通过 CDN 就近下载，配合 Range 回源支持断点续传。
• 发布预热：大版本上线前把资源推到全球边缘，避免开服瞬间回源洪峰。
• 抗 DDoS：游戏是 DDoS 重灾区，CDN/Anycast 清洗 + 源站隐藏是基本盘。

T11.4 金融与政企

• 合规与私有化：数据不出域，常采用私有化/专属节点部署（如金融云、政务云内的 CDN）。
• 等保与安全：WAF、漏扫、审计日志满足等保要求；交易链路强制 HTTPS + mTLS 回源。
• 高可用：多活架构下，CDN 配合全局流量调度实现异地容灾。

T11.5 政务、医疗与信创

这类场景强调自主可控与数据主权：倾向使用国产软硬件栈（信创）、私有化 CDN、数据不出省/不出境。选型时把“合规”权重放到最高，性能次之。

T11.6 出海业务

• 全球加速：用国际厂商（Cloudflare/Akamai/CloudFront）覆盖海外，国内用本地厂商，按地域调度。
• 数据合规：欧洲需关注 GDPR，数据跨境要评估合法性；部分地区要求本地化存储。
• 多 CDN 互补：不同厂商在不同大洲质量不同，按地域分流最优化验。

T11.7 在线教育与知识付费

• 课程点播：长视频分片 + 防盗链 + 签名 URL，防止录屏外泄（虽无法完全杜绝，但提高门槛）。
• 直播课：低延迟互动 + 弹幕/白板 WebSocket 加速。

T12.1 CDN 日志里有什么

原始日志（或实时日志流）通常包含这些字段，读懂它们才能分析问题：

T12.2 一条真实风格日志示例

2026-08-22 10:01:23 203.0.113.5 POP-Shanghai GET /img/logo.png 200 HIT 4821 Mozilla/5.0 -
2026-08-22 10:01:24 198.51.100.7 POP-Beijing GET /api/user 200 MISS 312 Chrome/120 -

从这两行就能看出：第一行命中（HIT）、来自上海节点；第二行未命中（MISS）、走了 API。把千万行聚合，就能画出命中率曲线、Top URL、地域热力。

T12.3 常用分析视角

T12.4 真实用户监控（RUM）与合成拨测

• RUM：在页面埋点，收集真实用户的首屏、首包、错误等真实体验数据，最贴近“用户实际感受”。
• 合成监控：从各地探针主动定时访问，模拟用户，适合“无人时发现异常”。
• 两者互补：RUM 看真实、合成看持续可用。

T12.5 设定 SLO 与告警

用可量化的服务水平目标（SLO）代替“感觉还行”：

示例 SLO：
- 缓存命中率 ≥ 90%（工作日）
- P95 TTFB ≤ 80ms（主要地域）
- 5xx 比例 ≤ 0.1%
- 可用性 ≥ 99.9%
告警：任一指标连续 5 分钟越界即通知值班

T12.6 一个分析小技巧：用 SQL 看 Top URL

-- 伪 SQL：找出流量最大的 10 个 URL
SELECT uri, COUNT(*) AS req, SUM(bytes) AS traffic
FROM cdn_logs
WHERE date = '2026-08-22'
GROUP BY uri
ORDER BY traffic DESC
LIMIT 10;

T13.1 边缘函数是什么

边缘函数（Edge Functions）让你把一小段代码部署到全球边缘节点，在每个请求经过时运行。它和“在源站跑代码”最大的区别是位置：代码就在用户附近执行，延迟极低，且能拦截/改写请求与响应。

T13.2 一个最小边缘函数示例

下面以类 Cloudflare Workers 的写法，演示“给响应加一个自定义头”和“按国家做简单改写”：

addEventListener('fetch', event => {
  event.respondWith(handle(event.request));
});

async function handle(req) {
  // 回源拿到原始响应
  let res = await fetch(req);
  // 克隆并可改写
  res = new Response(res.body, res);
  res.headers.set('X-Served-By', 'edge-function');
  // 简单的 A/B：按 cookie 分流
  const group = req.headers.get('cookie')?.includes('ab=B') ? 'B' : 'A';
  res.headers.set('X-AB', group);
  return res;
}

T13.3 边缘能做什么（实战场景）

• A/B 测试 / 灰度：在边缘按比例或按 cookie 把用户导向不同版本，无需改源站。
• 个性化注入：根据用户地域、设备，注入对应语言/推荐内容。
• 图像实时处理：边缘按设备尺寸/格式实时裁剪、转 WebP/AVIF，省去多份原图。
• 鉴权与防盗链：在边缘校验签名 URL、Referer，非法请求直接拦截，不回源。
• 请求改写：重写 URL、追加头、合并/拆分 API 请求（边缘 BFF）。

T13.4 边缘 AI 推理：在边缘跑模型

随着 WASM 与轻量运行时成熟，部分推理可下沉到边缘：

• 内容审核：在边缘对上传图片/文本做轻量分类，拦截违规再回源。
• 图像分类/标签：摄像头类 IoT 场景在边缘做预处理，只上传结果。
• 向量检索 / 语义缓存：边缘做简单向量匹配，命中相似问答直接返回。
• 大模型结果缓存：把大模型生成的常见回答缓存在边缘，降低推理调用与延迟。

T13.5 边缘函数的注意点

T14.1 反模式清单

T14.2 一个典型翻车现场

事件：某站把首页 HTML 缓存 24 小时，运营改了活动文案发布后，用户仍看到旧文案，客诉暴涨。
根因：反模式 #1 + 没配置主动刷新。
修复：首页改缓存 2 分钟；发布流程接 CDN purge 接口，发布即刷新；静态资源用 hash 长缓存。
复盘：缓存时长应与“内容更新频率”匹配，并用刷新机制兜底，而不是靠长 TTL 偷懒。

T14.3 自检清单（上线前过一遍）

1. 缓存键是否规范化（忽略无关参数）？
2. 动态内容是否按身份隔离或不缓存？
3. HTTPS 是否无混合内容？
4. 源站 IP 是否仅对 CDN 开放？
5. 是否配置了命中率/5xx/回源告警？
6. 是否有多 CDN 或回滚预案？
7. WAF 是否先观察后拦截？
8. 大文件是否开启 Range 回源？

T15.1 实验目标与拓扑

我们要模拟：一个源站 + 两个边缘缓存节点。用户访问边缘，边缘命中则返回、未命中则回源。你会亲眼看到 X-Cache-Status 从 MISS 变 HIT。

用户 ──▶ edge1 (Nginx 缓存) ──┐
用户 ──▶ edge2 (Nginx 缓存) ──┼──▶ origin (源站 Nginx)
                               │

T15.2 准备源站

用任意静态服务器充当源站。例如用 Python 起一个简单服务，放一个 index.html 和一张图：

# 源站目录结构
origin/
  index.html
  logo.png
# 启动（端口 8080）
python3 -m http.server 8080 --directory origin

T15.3 边缘节点的 Nginx 缓存配置

边缘 Nginx 的关键，是开启 proxy_cache 并把状态透出来：

http {
  proxy_cache_path /tmp/cache levels=1:2 keys_zone=cdn:10m max_size=1g inactive=60m;
  server {
    listen 80;
    location / {
      proxy_pass http://origin:8080;
      proxy_cache cdn;
      proxy_cache_key $scheme$host$request_uri;
      proxy_cache_valid 200 10m;
      add_header X-Cache-Status $upstream_cache_status;  # MISS / HIT / EXPIRED
      proxy_cache_lock on;                                # 请求合并，防惊群
    }
  }
}

T15.4 用 docker-compose 编排

services:
  origin:
    image: nginx:alpine
    volumes: ["./origin:/usr/share/nginx/html:ro"]
  edge1:
    image: nginx:alpine
    ports: ["8081:80"]
    volumes: ["./edge.conf:/etc/nginx/nginx.conf:ro"]
    depends_on: [origin]
  edge2:
    image: nginx:alpine
    ports: ["8082:80"]
    volumes: ["./edge.conf:/etc/nginx/nginx.conf:ro"]
    depends_on: [origin]

T15.5 验证：看缓存生效

# 第一次：MISS（回源）
curl -I http://localhost:8081/logo.png | grep X-Cache-Status
# 第二次：HIT（命中）
curl -I http://localhost:8081/logo.png | grep X-Cache-Status
# 换 edge2，首次也是 MISS，说明两节点各自缓存
curl -I http://localhost:8082/logo.png | grep X-Cache-Status

当你看到第一行 MISS、第二行 HIT，恭喜——你刚刚亲手验证了 CDN 最核心的机制。

T15.6 进阶挑战

• 把 proxy_cache_key 加上 $query_string 再试，观察带参请求如何变成“新资源”。
• 把 TTL 改短（如 10s），sleep 后请求看 EXPIRED。
• 用 ab 或 wrk 压测，对比“直连源站”和“经边缘”的吞吐差异。
• 尝试给边缘加一个 Lua 脚本（OpenResty），在响应里注入自定义头，体验“边缘计算”。

T16.1 CDN 在云原生架构里的位置

在 Kubernetes 体系中，外部流量通常这样走：用户 → CDN（边缘加速/安全）→ Ingress / Gateway → Service → Pod。CDN 是流量的“第一公里”，负责把大多数静态与可缓存请求在边缘消化掉，只把真正需要计算的动态请求送到集群内部。

T16.2 Ingress、Mesh 与边缘的关系

一句话：CDN 管“外到边”，Mesh 管“内到内”，两者通过 Ingress/Gateway 衔接。

T16.3 边缘 K8s 与分布式边缘

随着边缘计算兴起，出现了把 K8s 能力下沉到边缘的项目（如 KubeEdge、OpenYurt、轻量 K3s 边缘节点）。思路是：用一套控制面管理成百上千个边缘站点，像管集群一样管 CDN 边缘。这让“在边缘跑有状态/复杂逻辑”成为可能，但仍要面对边缘网络不稳定、资源受限等现实。

T16.4 用 GitOps 管理 CDN 配置

CDN 的缓存规则、WAF 规则、边缘函数，本质是“基础设施配置”。最佳实践是：

• 把配置写进 Git 仓库（YAML / Terraform / 厂商 CLI 脚本）；
• 通过 CI 在合并时自动校验、预览、再下发；
• 保留历史，出错可回滚——和管代码一样管 CDN。

这样能避免“控制台手改、没人知道改了啥”的混乱，也让多环境（测试/预发/生产）保持一致。

T16.5 可观测性统一

把 CDN 日志/指标接入统一平台（如 Prometheus + Grafana、ELK），与后端服务的 traces 打通，才能实现端到端追踪：用户请求慢，到底是 CDN 边缘慢、回源慢、还是源站慢？统一视图一查便知。

T16.6 给架构师的 checklist

1. 明确哪些流量该在 CDN 层终结（静态、可缓存、边缘逻辑）；
2. 动态流量用全站加速 + 合理回源策略；
3. CDN 配置纳入 GitOps，禁止裸手改生产；
4. 把 CDN 日志接入统一可观测平台；
5. 为多 CDN / 回滚预留切换能力。

T17.1 CDN vs 反向代理

关系：CDN 的边缘节点本质就是分布式的反向代理集群。你在本机 Nginx 做的事，商业 CDN 在几千个节点上替你做了。

T17.2 CDN vs 负载均衡（LB）

LB 解决“把请求分给哪台服务器”，CDN 解决“内容放在离用户多近的地方”。两者常配合：CDN 做全局调度（GSLB），LB 做节点内部分发（LSLB）。不要把它们对立——CDN 内部就包含多层负载均衡。

T17.3 CDN vs 镜像 / 容灾复制

• 镜像：把整站/整库复制到异地，内容一致性靠同步机制，成本高、实时性差。
• CDN：按需缓存，用户要什么才就近存什么，命中即返回，未命中才回源。更轻、更省。

简单说：镜像像“把整超市搬去外地”，CDN 像“在外地开个按需补货的便利店”。

T17.4 CDN vs P2P

• CDN：用厂商自己的节点带宽，质量可控、稳定，但大流量成本高。
• P2P：利用观看者之间的带宽互传，成本极低，但质量波动、弱网/冷启动体验差。
• 混合：超大并发（热门赛事、游戏更新）常用 P2P+CDN，CDN 补“种子”，P2P 分摊流量。

T17.5 回源（Pull）vs 推送（Push）

T17.6 边缘 vs 核心（源站）

边缘是离用户近的缓存/计算层，强调“近、快、分布式”；核心/源站是内容的“真相来源”，强调“权威、可写、有状态”。CDN 的智慧，在于让绝大部分请求止步于边缘，只把必要的写/动态请求送到核心。

T17.7 Anycast vs 普通单播调度

• 普通 DNS 调度：不同用户解析到不同 IP（按地域），切换受 DNS 缓存影响，不够实时。
• Anycast：多节点用相同 IP，网络路由自动把流量引到最近节点，切换极快、天然抗 DDoS，但需 BGP 广播能力（多为大厂）。

T17.8 全站加速 vs 静态 CDN

T17.9 命中 / 未命中 / 过期 / 回源

• HIT（命中）：边缘有有效副本，直接返回。
• MISS（未命中）：边缘没有，需回源。
• EXPIRED（过期）：有副本但 TTL 到了，需回源刷新。
• STALE / Revalidated：旧副本先返回（stale-while-revalidate）或回源校验后复用。

T18.1 为什么要测，而且要“对照测”

CDN 的价值必须用数据说话。最可靠的证明是对照实验：同一资源，在“直连源站”和“经 CDN”两种路径下分别测量，差异即收益。否则“感觉快了”可能只是网络波动或心理作用。

T18.2 测什么指标

T18.3 常用工具

• curl -w：一行命令看 TCP/TLS/TTFB 各阶段耗时，适合快速验证。
• wrk / ab：压测吞吐与并发，对比直连与经 CDN 的承载能力。
• WebPageTest / Lighthouse：可视化首屏、瀑布图、Web Vitals。
• 厂商拨测 / RUM：多地域真实用户体验与持续监控。

T18.4 正确的测试姿势

1. 分“冷/热”两种态：第一次请求（冷，通常 MISS）和后续请求（热，HIT）延迟差异巨大，要分别报告。
2. 多地域：至少在用户集中地各取一个拨测点，单点结果不具代表性。
3. 多时段：晚高峰与凌晨网络质量不同，关键结论应跨时段验证。
4. 排除本地干扰：本地 Wi-Fi、VPN、DNS 缓存都会污染结果，优先用云上探针。
5. 样本足够：单次测量意义有限，取多次中位数/P95。

T18.5 常见测试陷阱

T18.6 一份测试报告模板

测试对象：首页 HTML / 商品图 / API
测试路径：A) 直连源站  B) 经 CDN
测试地域：北京 / 上海 / 广州 / 海外
测试时段：2026-08-22 20:00（晚高峰）
结论示例：
- 商品图 TTFB：直连 320ms → CDN 38ms（热命中）
- 首页 HTML：直连 280ms → CDN 52ms
- 命中率：96%，源站出流量下降 94%
- 建议：全量接入，静态资源 TTL 延长至 30 天（配合 hash）

Q1：用了 CDN，还需要源站吗？

需要。CDN 是缓存与加速层，源站仍是内容的“真相来源”。CDN 只在未命中时回源。

Q2：CDN 会让 SEO 变差吗？

一般不会，反而常因访问更快、更稳定而利好 SEO。注意：隐藏源站、保持可抓取、避免误拦截爬虫即可。

Q3：免费 CDN 够用吗？

个人站、小项目通常够。Cloudflare 免费层含 CDN、DNS、基础安全；进阶需求（更强 WAF、中国节点、专属支持）再付费。

Q4：CDN 能加速数据库 / API 吗？

直接缓存数据库不行（数据实时、个性化）。但 API 可用全站加速（路由/协议/连接复用）提速；公开只读数据可谨慎缓存。

Q5：怎么知道命中率？

看响应头（X-Cache / CF-Cache-Status）或控制台；大规模用日志聚合计算 HIT/(HIT+MISS)。

Q6：CDN 缓存和浏览器缓存有什么区别？

浏览器缓存存在用户本地；CDN 缓存存在边缘节点，服务所有就近用户。两者互补：CDN 减源站压力，浏览器缓存减重复请求。

Q7：海外用户访问国内 CDN 慢怎么办？

国内节点对海外覆盖有限。出海用国际厂商（Cloudflare/Akamai/CloudFront）或在海外布点，按地域调度。

Q8：HTTPS 证书谁管？

商业 CDN 多免费提供并自动续期；也可上传自有证书。边缘到源站的回源证书需自行保证可信。

Q9：回源 IP 段在哪查？

各厂商文档提供最新回源 IP 段，源站防火墙应只放行这些段，并定期更新。

Q10：CDN 能防 CC / DDoS 吗？

能防大部分 L3/L4 与基础应用层攻击；高级 WAF/Bot 规则可挡 CC。极复杂攻击仍需配合源站防护与多 CDN。

Q11：改了静态资源，多久生效？

取决于 TTL。带 hash 文件名可立即换 URL 生效；否则等 TTL 过期或主动 purge。建议静态资源长缓存 + hash。

Q12：多 CDN 怎么切换？

通过智能 DNS（按健康/地域返回不同 CNAME）、HTTPDNS 客户端调度，或 Anycast 单 IP 多厂商。

Q13：CDN 和对象存储什么关系？

对象存储（如 OSS/COS/S3）常作源站，CDN 加速其对外访问。很多厂商提供“存储 + CDN”一站式。

Q14：直播延迟怎么降？

用低延迟方案（LL-HLS / WebRTC），减少分片时长与缓冲；边缘低延迟转封装也很关键。

Q15：边缘函数能直连数据库吗？

不建议直连（延迟高、连接数受限）。优先用 KV/缓存服务或经 API 到源站，重查询放中心。

Q16：账单突然飙升怎么办？

先查是否被盗链/被刷（Referer、突发流量）；开防盗链、限速、签名 URL；长期优化缓存与压缩降流量。

Q17：国内接入 CDN 必须备案吗？

在中国大陆提供服务，域名通常需 ICP 备案才能用大陆节点。未备案只能用境外节点。

Q18：CDN 会影响数据采集 / 统计吗？

可能改变客户端 IP（看到的是边缘 IP）。需配置“真实客户端 IP”头（如 X-Forwarded-For / True-Client-IP）给源站。

Q19：如何确认 CDN 已生效？

curl -I 看是否有 CDN 特征头；dig 看是否解析到 CDN IP；对比直连与经 CDN 的 TTFB。

Q20：小网站值得上 CDN 吗？

值得。免费层零成本带来加速+安全+隐藏源站三重收益，几分钟即可接入。

A. 术语表（速查）

B. 动手实验（建议按顺序做）

1. 实验1 · 看头识 CDN：对一个已知用了 CDN 的网站（如 GitHub、Wikipedia）执行 curl -I，找出它的缓存状态头与 Server 头。
2. 实验2 · 本地缓存：用 Docker 起一个 Nginx，配置 proxy_cache，请求同一 URL 两次，观察 X-Cache-Status 从 MISS 变 HIT。
3. 实验3 · 对比协议：用浏览器 DevTools 的 Network 面板，分别观察同一资源在 HTTP/1.1 与 HTTP/2 下的加载表现（开启“协议”列）。
4. 实验4 · 接入实战：把个人博客/静态页接入 Cloudflare 免费版（或国内某 CDN），配置缓存规则与强制 HTTPS，并用拨测工具对比接入前后首包时间。
5. 实验5 · 边缘函数：在 Cloudflare Workers / 腾讯云边缘函数中写一段代码，给所有响应加一个自定义 Header，体验“边缘计算”。

C. 延伸学习资源

• 官方文档：Cloudflare Docs、AWS CloudFront Docs、阿里云/腾讯云 CDN 文档——最权威的能力与配置说明。
• 协议标准：RFC 9110（HTTP Semantics）、RFC 9114（HTTP/3）、RFC 9000（QUIC）——想深入底层必读。
• 开源项目：Nginx、Varnish、Apache Traffic Server、Caddy、HAProxy、Envoy 的官方文档与源码。
• 实践社区：各大厂商的开发者社区、技术博客（Web 性能、前端性能优化专题）。

D. 常见误区澄清