CDN 与静态资源加速核心机制：从回源到边缘计算

本文拆解 CDN 如何让"就近拿到内容"成为现实：调度方式、缓存分层与命中策略、回源与刷新的一致性代价，以及边缘计算带来的新能力。

为什么需要 CDN？

没有 CDN：全球用户 → 中心机房源站
  1. 物理延迟：跨洋 RTT 200ms+，TCP 慢启动还没跑完用户就走了
  2. 带宽成本：出口带宽单价远高于运营商本地交付
  3. 单点风险：所有流量压在一处，突发即宕
  4. 最后一公里：运营商跨网互访慢（历史南电信北联通问题）

CDN 的本质：把内容"复制"到离用户近的节点，用空间换时间。
  收益 = 延迟下降 + 源站减压 + 带宽降本 + 抗突发
  代价 = 一致性（内容更新有传播时延）+ 缓存治理复杂度

请求路径全解

用户访问时，请求大致这样走：先做 DNS 解析，用户的 Local DNS 把域名按 CNAME 指到 CDN 的调度域名，调度 DNS（GSLB）根据来源 IP、Anycast 或 HTTPDNS 选出一个最优的边缘节点。

请求到达边缘节点（Edge PoP）后，先查缓存：命中就直接返回，并带上缓存头；没命中就往上一层的区域汇聚节点（Regional PoP）找，命中就返回；再没命中才回源到 Origin（源站、对象存储或负载均衡）。由于多个边缘同时未命中时，回源请求会在中间层被收敛成少量请求，源站最终只面对"全网都没有"的极少数请求。

这三层结构的目的就是逐层吸收流量，把源站的压力降到最低。

调度：怎么把用户送到"对的节点"

调度输入：节点负载、健康状态、带宽水位、运营商归属、实时 RTT 探测。

缓存：CDN 的心脏

命中与失效的规则

缓存键（Cache Key）默认 = URL（含 query？）取决于配置：
  - 忽略无关参数（utm、时间戳）能极大提升命中率（合并缓存）
  - 但鉴权 token 在 query 时又要区分 → 白名单参数策略

TTL 决策优先级（常见）：
  源站 Cache-Control: max-age > CDN 目录/后缀规则 > 默认
  no-store / no-cache / private 一律不缓存（配错 = 登录态串号事故）

分层过期（实践标配）：
  图片/JS/CSS（带 hash 文件名）：max-age=31536000, immutable（一年强缓存）
  HTML 入口： no-cache 或短 max-age + must-revalidate（协商缓存 304）
  → 前端"内容 hash + 入口不缓存"发布模型与 CDN 天然契合

高级缓存能力

 stale-while-revalidate：过期后先返回旧内容、后台异步回源刷新
   → 命中率与新鲜度双赢，适合更新不敏感的大资源
 Range 回源/分片缓存：大文件只缓存/回源命中的字节段，
   边下边播场景避免整文件回源
 缓存击穿防护：同 URL 并发未命中 → 只放一个请求回源（合并请求）
 冷流/热流：热门资源提前预热（prefetch API 把内容推到边缘），
   大促/发版前必做，否则开售瞬间回源打穿源站

回源与一致性：改文件多久全网生效？

传播链：源站更新 → 各层缓存仍是旧副本 → 用户陆续命中旧内容
两种解法：
  1. 版本号/内容 hash 换 URL（推荐）：天然无一致性问题，
     旧 URL 随 TTL 自然淘汰 —— 前端构建 + 不可变缓存的标准答案
  2. 刷新（Purge）：按 URL/目录调 CDN API 让边缘删缓存
     - 秒级~分钟级生效，全网 PoP 收敛时间 SLA 要心里有数
     - 预热与刷新成对使用：刷 HTML 入口 + 预热新资源
  3. 子资源被 HTML 引用且 URL 不变（如 /api/config.json）：
     用短 TTL + stale-while-revalidate 折中

坑：刷新只清边缘，中间层/运营商 Local 缓存/浏览器强缓存层层漏网，
   "用户还是看到旧版"多数不是 CDN 没刷干净，而是本地强缓存。

动态加速与全站加速

静态：缓存命中为主 → 靠边缘副本
动态：不可缓存（带鉴权、实时数据）→ 靠"路"不靠" cache"
  源站 ↔ 边缘之间走 CDN 私有骨干网：
    - 建优：绕过公网拥塞路径，择优选路（多跳中继、分片回源）
    - 协议优化：长连接池复用、TCP 参数调优/BBR、HTTP/2·HTTP/3 到端
    - 安全：WAF、CC 防护、防盗链（Referer/UA/IP 频控/URL 鉴权签名）
  URL 鉴权（A/B/C 型签名）是 CDN 场景防盗链主力：
    源站生成带过期时间的签名 URL → 边缘校验 → 拒绝裸链与爬虫

典型组合：静态走缓存域名（长 TTL）、API 走动态加速域名（no-store）、
        上传走边缘直传对象存储（分片 + 断点续传）。

边缘计算：从"缓存副本"到"就近执行"

演进：只读缓存 → 可编程缓存（边缘函数，请求级改写）→ 边缘运行时
  Cloudflare Workers / 阿里云 ESA / Fastly Compute@Edge

能做什么：
  - A/B 分流、个性化裁剪（按 UA/地域/语言改写 HTML 与图片格式）
  - 鉴权前置：token 校验在边缘做，不过源省 RTT
  - 协议转换、响应聚合（多源拼一页）
  - 灰度与故障切换：边缘探测源站健康自动切流
  - KV 配置下发：全局低延迟读配置（毫秒级传播）

心智模型：把"每个请求都要执行的业务逻辑前哨"搬到离用户 20ms 的地方；
  但计算贵、状态难共享、调试链路长 → CPU 时间片按次计费，
  重逻辑仍应回中心，边缘只做"轻决策 + 快返回"。

实战：命中率与排障 checklist

体检指标（运营商/云控制台都有）：
  命中率（字节命中/请求命中分开看）、回源带宽比、边缘 RTT 分布、
  4xx/5xx 比例（突增 = 某节点或某规则出问题）

命中率低排查顺序：
  1. Cache Key 是否把随机参数（时间戳/trace id）当成了不同资源
  2. HTML/API 是否误配了缓存（既危害一致性又拉低有效命中）
  3. TTL 是否过短或被源站 no-store 拖死（抓响应头确认）
  4. 节点分布与调度是否让长尾地区跨区回源

典型事故复盘：
  - 登录态串号：HTML 配了强缓存且含 Set-Cookie → 缓存 key 未区分用户
    修法：带鉴权响应一律 private/no-store，或 key 加 cookie 指纹
  - 发布后白屏：刷了 HTML 没预热新 hash 资源，边缘并发 404 回源
  - 图片灰度异常：忽略参数的合并缓存让"尺寸后缀"丢失，按参数拆分
  - HTTPS 证书链不全：部分安卓机型校验失败，用 SSLLabs 全协议复测

总结

理解 CDN 的关键在于：它用"复制 + 就近"对抗物理延迟与带宽成本，但每一次复制都在和一致性做交易——架构上把"可缓存的静态"与"不可缓存的动态"彻底分开，用内容 hash 让缓存永不撒谎，再用骨干网和边缘函数解决剩下那半部分，这套分工就是现代全站加速的骨架。