漫话：如何给女朋友解释什么是 CDN？
Category（分类）: Other Status: 已整理
本文保留原文用“菜鸟仓配网络”解释 CDN 的故事线和配图，并修正 DNS 调度、缓存命中、回源、DDoS 防护等容易被过度简化的内容。原文配图已下载到本文同目录的
images/文件夹。
一、故事开始
周六晚上七点多，我正在看书，女朋友突然跑过来问她的 iPad 去哪儿了，显得很着急。
拿到 iPad 后她就不再理我了。作为程序员，我反而开始好奇：这么大的直播流量，虎牙到底能不能扛得住？我过去看了一下，发现直播并没有想象中那么卡顿。
原文提到，2018 年阿里云曾为虎牙提供边缘节点服务（ENS），把转码、分发和部分弹幕处理放到更接近用户的节点，以降低中心带宽和时延压力。具体产品架构和数据属于当时的案例，今天不能直接当作所有直播平台的通用实现；直播 CDN、实时互动、边缘计算和云厂商产品会随时间变化。
直播结束后，女朋友终于问我：“到底什么是 CDN？”
二、什么是 CDN
CDN 的全称是 Content Delivery Network，即内容分发网络。它通常由分布在不同地区和网络中的边缘节点（PoP）组成，用来让用户从相对合适的网络位置获取内容，减少源站的重复请求和长距离传输。
用仓库来类比
我们都用过天猫超市。商品不会全部存放在一个遥远的大仓库里，而是可以提前进入不同城市的仓库。消费者下单后，系统会根据库存、地址、配送线路和仓库负载，选择合适的仓库发货。
网站也会把适合缓存的内容放到边缘节点，例如：
- HTML、JavaScript、CSS 和字体；
- 图片、音频、视频和下载文件；
- HLS/DASH 等直播或点播分片；
- 在满足安全条件时缓存部分公开 API 响应；
- 在边缘执行重写、鉴权、压缩、图片处理或轻量计算。
用户请求到来时，CDN 会尽量从合适的边缘节点返回内容，而不是每次都让所有用户直接访问源站。它就像“离消费者更近的仓库”，但真正的选择还要考虑网络拓扑、运营商、节点健康、容量、缓存命中率和策略，并不只是地理距离最近。
因此，CDN 可以用于站点加速、下载、图片分发、点播、直播和部分边缘安全场景。它可能降低时延、提高吞吐、减轻源站带宽和连接压力，但不是自动变快的开关，也不能替代源站扩容、缓存策略、数据库优化或应用安全。
三、CDN 的基本工作过程
1. 不使用 CDN 的简化过程
用户访问源站时，通常会经历：
浏览器和系统缓存
-> stub resolver / 递归 DNS
-> 得到 A、AAAA 或其他接入地址
-> TCP/TLS 或 QUIC 建立连接
-> 发起 HTTP 请求
-> 源站处理请求
-> 返回响应
更具体地说：
- 用户在浏览器地址栏输入 URL；
- 浏览器、操作系统、hosts 和本地网络设备共同决定 DNS 查询路径；
- 递归 DNS 解析器从缓存或权威 DNS 得到地址；
- 浏览器根据地址建立 TCP/TLS 或 QUIC 连接；
- 浏览器携带原始域名发起 HTTP 请求；
- 源站处理请求并返回资源。
DNS 只负责名称解析，返回 IP 不代表网页已经加载完成。后续还可能有连接、TLS、排队、服务器处理、传输、浏览器解析和渲染等成本。
2. 使用 CDN 的典型过程
假设用户访问：
https://static.example.com/app.js
DNS 可能配置为：
static.example.com CNAME customer.cdn.example.net
一个更准确的 CDN 访问过程如下：
- 浏览器和操作系统检查缓存、连接复用和 hosts；
- 递归 DNS 查询
static.example.com，必要时继续解析 CNAME 链； - CDN 的权威 DNS 或全局流量调度系统返回一个接入地址；有些 CDN 还会使用 Anycast，让多个地点通过 BGP 宣告同一个入口 IP，这与基于 DNS 返回不同节点地址是两种不同的调度方式，产品也可能组合使用；
- 浏览器使用原始域名建立 HTTPS 连接，TLS 的 SNI 和 HTTP Host/
:authority仍然通常是业务域名； - 请求到达边缘节点后，CDN 根据域名、路径、查询参数、请求头和策略构建缓存键；
- 如果对象命中且仍然新鲜，边缘节点直接返回；
- 如果未命中、过期、被绕过或需要重新验证，边缘节点向上一级缓存、Origin Shield 或源站请求；
- 源站响应返回给用户，并在符合缓存策略时写入边缘缓存。
原文流程图中有几处需要特别修正：
- DNS 查询通常只包含域名和记录类型，不能看到完整的 URL 路径；
/images/logo.png会在 HTTP 请求到达 CDN 后才参与边缘路由和缓存键计算； - 客户端不一定直接拿到“全局负载均衡设备的 IP”，可能拿到 Anycast 地址、边缘入口地址或多级 CNAME 的结果；
- “最近节点”是便于理解的说法，实际调度可能按递归解析器位置、ECS、运营商、网络质量、节点容量和健康状态综合决定；
- CNAME 是 DNS 名称别名，不是 HTTP 302 跳转，也不是把文件立即复制到 CDN；
- CDN 是否命中缓存由缓存键、缓存状态、响应头和产品规则共同决定，不是只要接入 CDN 就一定命中。
四、缓存命中、未命中和回源
1. Cache HIT 和 Cache MISS
- Cache HIT：边缘节点中有符合缓存键的对象，并且对象仍然可以直接使用；
- Cache MISS：边缘节点没有对象，需要从上游缓存或源站取得；
- 过期/重新验证：对象还在，但需要根据
ETag、Last-Modified或 CDN 规则向上游确认； - 绕过缓存：请求带有登录 Cookie、Authorization、特定查询参数或产品规则，CDN 直接回源；
- 失效（purge/invalidation）：运营方主动删除或标记某些边缘对象，使后续请求重新获取。
一个请求 MISS 并不意味着源站一定立刻被打穿。很多 CDN 使用分层缓存和 Origin Shield，让多个边缘节点共享更上层缓存，减少同一个对象对源站的并发回源。
2. Cache-Control 决定共享缓存行为
静态资源使用内容哈希文件名时，可以采用较长的新鲜度：
Cache-Control: public, max-age=31536000, immutable
HTML 或公开 API 可以根据发布策略使用共享缓存时间和后台重新验证：
Cache-Control: public, max-age=0, s-maxage=60, stale-while-revalidate=30
ETag: "catalog-v42"
用户私有或带权限的数据通常不应进入共享 CDN 缓存：
Cache-Control: private, no-store
需要区分：
max-age主要描述浏览器等私有缓存的新鲜度；s-maxage优先描述共享缓存（如 CDN）的新鲜度；no-cache通常表示使用前必须重新验证，不等同于“不缓存”；no-store表示不要存储响应；stale-while-revalidate是否支持、允许多长时间提供旧内容，要看缓存实现和配置；Vary、Cookie、Authorization、查询参数和 CDN 自定义规则都可能改变缓存结果。
3. 版本化与刷新
常见的缓存更新方式有三种：
- 文件名指纹：
app.abc123.js更新内容就改变文件名，适合长期缓存的静态资源； - CDN 主动失效：按 URL、目录或标签清理对象，通常会产生 API 调用、传播延迟或费用；
- 短 TTL 和条件请求：适合需要较快更新的 HTML 或公开数据，但会增加回源和验证请求。
不要把“清除浏览器缓存”和“清除 CDN 缓存”混为一谈。发布后仍看到旧文件时，应检查浏览器缓存、Service Worker、CDN 响应头、上游缓存和源站版本。
五、CDN 的组成
原文把 CDN 分为中心节点和边缘节点，这是一种便于理解的教学模型。不同厂商的名称不同，现代 CDN 可能由以下部分组合而成：
- 控制面：配置域名、证书、缓存规则、回源策略、WAF、日志和发布；
- 流量调度：DNS 调度、Anycast、线路策略、健康检查和容量管理；
- 边缘节点：接收客户端请求，处理 TLS、HTTP、缓存和边缘规则；
- 分层缓存或 Origin Shield：减少多边缘节点同时回源；
- 源站：保存原始内容，可能是对象存储、Web 服务、API、媒体处理集群或数据库前的应用层；
- 边缘函数/边缘计算：在靠近用户的节点执行重写、鉴权、A/B 测试和轻量逻辑；
- 可观测性系统：收集命中率、回源率、状态码、时延、带宽、错误和安全事件。
CDN 节点数量和“覆盖多少城市”会随产品、地区和时间变化。不能因为厂商宣传了大量节点，就推断所有用户都会访问到最近或最快的节点；应查看自己的真实访问结果。
六、CDN 的四类技术能力
用仓配网络来类比，CDN 通常需要解决四件事：内容如何发布、内容放在哪里、用户请求如何路由、整个系统如何管理。
1. 内容发布
内容可以由源站主动预热、用户首次访问时按需拉取，或通过对象存储同步到边缘。主动预热能减少首批用户 MISS，但会增加发布流程和存储成本；按需回源简单，却可能在热点刚出现时产生回源洪峰。
2. 内容存储
源站保存原始版本，边缘节点保存可缓存副本。缓存对象的大小、淘汰策略、TTL、容量和分层方式都会影响命中率。视频分片、图片变体和带查询参数的资源尤其需要设计稳定的缓存键。
3. 内容路由
DNS、Anycast、HTTP 层和边缘规则都可能参与路由。DNS 适合按解析位置和网络环境做较粗粒度的入口选择；请求到达边缘后，CDN 才能看到 Host、路径、查询参数、Cookie 和请求头，并进行更细粒度的缓存和转发。
4. 内容管理与观测
需要持续观察：
- 命中率、回源率和缓存对象大小；
- 首字节时间、下载速度和连接失败率；
- HTTP 状态码、源站错误和边缘错误；
- 不同地区、运营商、IPv4/IPv6 和设备的表现；
- 证书、缓存规则、WAF、带宽和费用变化。
七、CDN 能做什么，不能做什么
适合 CDN 的内容
- 带版本号的 JavaScript、CSS、字体和图片；
- 公开、可共享的下载文件；
- 图片压缩、格式协商和尺寸变体；
- 视频点播文件和分片；
- 经过严格缓存设计的公开 GET/HEAD API；
- TLS 终止、WAF、限速、机器人管理和边缘重写。
不应直接缓存的内容
- 与用户身份、Cookie、
Authorization或权限相关的响应；带 Cookie 或Authorization的请求经常会被默认绕过或设为不可共享，但这取决于 CDN 配置，不能把它当作自动的安全保证； - 购物车、订单、支付、个人资料等私有数据；
- 未明确区分租户、地区和语言的响应；
- 会改变状态的 POST、PUT、PATCH、DELETE 请求；
- 包含敏感信息但没有明确
Cache-Control的错误页面。
即使是 GET 请求，也不代表一定可以共享缓存。必须确认缓存键、请求头、响应头和业务权限不会让用户 A 看到用户 B 的结果。CDN 的 WAF 和 DDoS 防护也不是万能的：源站暴露、规则配置错误、应用漏洞、登录接口滥用和大规模攻击仍需要独立防护。
实时直播和互动业务还要区分：
- 视频分片通常可以缓存和就近分发；
- 推流、低延迟信令、WebSocket 和个性化弹幕需要长连接或动态处理；
- CDN 是否支持某种协议、缓存模式和低延迟方案，要看具体产品，不能把静态文件 CDN 的模型直接套到实时业务。
八、现代 CDN 与网络协议
今天的 CDN 往往同时处理：
- HTTP/1.1、HTTP/2 和 HTTP/3/QUIC；
- TLS 证书、SNI、OCSP 和安全响应头；
- Brotli、Gzip、图片格式协商和响应压缩；
- IPv4/IPv6 双栈和多线路调度；
- WAF、DDoS 清洗、Bot 管理和速率限制；
- 边缘函数、图片处理、A/B 测试和请求重写。
HTTP/3 使用 QUIC，能改善部分网络条件下的连接建立和丢包恢复，但是否收益明显仍取决于客户端、网络和 CDN 节点。启用 HTTP/3 也不能掩盖源站慢、缓存未命中或 JavaScript 阻塞等问题。
九、接入 CDN 的实用检查清单
- 先明确缓存对象。 静态资源、HTML、公开 API、私有 API、下载和视频分片分别设计策略。
- 保护源站。 使用源站专用域名、访问控制、鉴权、回源 Token 或云厂商提供的源站保护，避免用户绕过 CDN 直接打源站。
- 配置 HTTPS。 检查证书、SNI、TLS 版本、HTTP/2/3 和回源协议，不要只在 CDN 边缘终止 TLS 后用不安全的明文回源。
- 设计缓存键。 明确 Host、路径、查询参数、Cookie、Authorization、语言和设备是否参与缓存；不要为了命中率盲目忽略参数。
- 使用文件指纹。 静态资源采用内容哈希文件名，减少“发布后清缓存”的依赖。
- 控制回源洪峰。 使用预热、分层缓存、请求合并和限流，但要结合厂商实现验证效果。
- 检查响应头。 关注
Age、Cache-Control、ETag、Via、X-Cache等诊断信息；不同厂商字段名称可能不同。 - 做真实区域测试。 从不同运营商、IPv4/IPv6、移动网络和海外网络检查 DNS、连接、证书、命中率和首字节时间。
- 建立失效和回滚流程。 发布规则、缓存刷新、证书变更和 WAF 调整都应可审计、可回滚。
- 不要只看带宽节省。 同时观察 LCP、TTFB、INP、错误率、转化率和源站成本。
十、总结
CDN 像一张分布式的“本地仓库网络”：它把可共享的内容放到靠近用户的节点，并通过 DNS、Anycast、边缘路由和缓存策略把请求送到合适的位置。它的核心收益通常来自：
- 减少用户到源站的距离和重复传输；
- 用边缘缓存承接热点请求；
- 降低源站带宽、连接和计算压力；
- 在边缘提供一部分安全、压缩和计算能力。
但 CDN 不是简单的“把所有文件提前复制到每个城市”，也不是只要节点多就一定快。只有缓存策略、缓存键、回源保护、网络调度、源站性能和真实监控一起设计，CDN 才能稳定地产生收益。