CDN 工作原理与架构详解：从边缘节点到全球分发
CDN（Content Delivery Network，内容分发网络）是一组在地理上广泛分布的服务器，通过在更靠近用户的位置缓存内容，来加速网页内容的交付。理解它的工作原理，是正确配置和发挥价值的前提。如果你还不熟悉基础概念，可以先阅读CDN 加速原理与配置入门。
一、CDN 的核心组成与请求链路
1.1 源站（Origin）
源站是内容的原始存放位置，也就是你的网站服务器或对象存储。CDN 不替代托管，它缓存的是源站内容的副本。源站通常位于某一个或某几个数据中心，距离大部分用户较远，这是网络延迟的主要来源。
1.2 边缘节点（Edge Node）
边缘节点是分布在全球各地的缓存服务器。CDN 服务商会在互联网交换点（IXP）等高速互联位置部署节点，让用户能就近连接。节点内部通常配备高速缓存（SSD）、负载均衡与网络优化能力。
1.3 一次完整的请求链路
用户 → DNS 解析 → 就近边缘节点 → 命中缓存？直接返回
→ 未命中？回源拉取 → 缓存 → 返回
当用户访问网站时，浏览器先通过 DNS 把域名解析到最近的边缘节点 IP；节点收到请求后，如果本地有缓存副本就直接返回；如果没有，则向源站回源拉取，缓存后返回给用户。这一条链路中，回源是否频繁，直接决定了源站压力和用户体验。
二、缓存与回源机制
2.1 缓存命中与未命中
缓存命中（Cache Hit）意味着边缘节点直接返回缓存内容，速度快、不占用源站带宽；未命中（Cache Miss）则需要回源，延迟和成本都更高。命中率是衡量 CDN 配置好坏的核心指标，关于如何提升命中率，可参考CDN 缓存命中率优化和CDN 缓存策略配置指南。
2.2 TTL 与缓存刷新
缓存副本存活多久由 TTL（Time to Live）决定。TTL 过短会导致频繁回源，过长则可能导致内容更新不及时。常见的做法是：静态资源（图片、CSS、JS、字体）设置长 TTL，HTML 页面设置短 TTL 或配合缓存刷新机制。
2.3 用响应头控制缓存行为
CDN 是否缓存、缓存多久，很大程度由源站返回的响应头决定。下面是一个典型配置示例：
# 静态资源：长 TTL + 指纹化文件名，避免更新后仍命中旧缓存
location ~* \.(css|js|png|jpg|webp|woff2)$ {
expires 30d;
add_header Cache-Control "public, max-age=2592000, immutable";
}
# HTML：短 TTL，允许 CDN 每次向源站校验
location / {
add_header Cache-Control "public, max-age=60, must-revalidate";
}
关键是"分级"而不是"一刀切"：图片、CSS、JS 这类内容用长 TTL，配合构建时生成带 hash 的文件名，让旧缓存自然失效；HTML 用短 TTL 并打开 must-revalidate，保证页面更新能尽快同步到边缘。很多网站命中率上不去，第一步要查的就是源站是不是压根没返回 Cache-Control 头。
三、Anycast 与全球分发
3.1 什么是 Anycast
Anycast 让多个地理位置不同的节点共享同一个 IP 地址。当用户请求该 IP 时，网络会自动把流量路由到距离最近的节点。这既是 CDN 实现"就近接入"的关键，也是高可用的基础——当某个数据中心故障时，Anycast 会自动把流量转移到其他可用节点，用户几乎无感知。
3.2 互联网交换点（IXP）
IXP 是不同网络运营商互连的高速交换点。CDN 服务商在 IXP 部署节点，能显著降低跨网传输的成本与延迟。这也是为什么大型 CDN 的节点密度和 IXP 覆盖广度，通常被当作衡量网络质量的重要指标。
四、CDN 加速的本质收益
4.1 缩短物理距离
内容离用户越近，往返延迟越低。把请求从"跨国访问"变成"同城访问"，往往能带来数十到数百毫秒的提升。
举一个可量化的例子：一个面向全球用户的英文站点，源站放在北美东部。没有 CDN 时，一位欧洲用户每次请求要跨越大西洋，往返延迟（RTT）通常在 90-140ms；接入在欧洲有边缘节点的 CDN 后，RTT 降到 20-40ms，首屏时间能省掉 150-300ms。对电商站来说，这部分延迟直接与跳出率、转化率相关——据 Google 的研究，移动端加载时间每增加 1 秒，转化率可能下降约 20%。换句话说，CDN 省下的不只是"快一点"，而是真实的订单。
4.2 降低源站带宽与成本
大部分请求由边缘节点直接响应，源站只需处理少量回源请求，带宽成本随之下降。这对带宽计费的云服务器尤为明显。
4.3 高可用与容灾
分布式架构天然具备冗余能力。单个节点故障时，负载均衡与智能故障转移会把流量重新分配到其他节点，网站可用性显著提升。
4.4 边缘安全
CDN 位于网络边缘，可以提前拦截 DDoS 攻击、恶意请求，并统一管理 TLS 证书。关于安全能力的详细说明，见CDN 安全防护能力。
常见问题（FAQ）
- 动态接口（API）能被 CDN 加速吗？ 可以，但要用对方法。全站走缓存会伤到登录态与个性化内容，通常的做法是：只缓存公开接口（如文章列表、价格信息），通过自定义缓存键区分地区/语言，动态请求回源。Cloudflare 等厂商还提供边缘函数（Worker）处理动态逻辑。
- CDN 能替代云服务器吗？ 不能。CDN 缓存的是"副本"，源站必须稳定在线；它解决的是分发距离，替代不了计算与存储。
- 命中率多高算正常？ 静态资源为主的站点做到 90% 以上很正常；带个性化与动态内容的站点命中率天然偏低，不必强求。重点是与同类站点对比、观察趋势，而不是追逐单一数字。
五、16IDC 观察：怎么把 CDN 用到极致
在 16IDC 我们经常遇到的一个误区是：以为接入 CDN 就等于"开了加速"。实际上，CDN 的效果取决于三个层面：
- 源站质量：源站响应慢、缺少必要的 Cache-Control 头，回源会拖垮整体体验；
- 缓存策略：不同内容类型的 TTL、缓存键设计是否合理，直接影响命中率；
- 调度质量：节点覆盖、Anycast 与线路调度是否贴合你的用户分布。
对大多数中小网站，建议从配置成熟的CDN 加速方案起步，再逐步深入到CDN 网络的底层优化。理解原理不是为了造轮子，而是为了在排查延迟、评估服务商、控制成本时能做出准确判断。
参考：Cloudflare 缓存文档 https://developers.cloudflare.com/cache/；MDN HTTP 缓存规范 https://developer.mozilla.org/docs/Web/HTTP/Caching