5 分钟了解 CDN 加速原理

Category（分类）: Other Status: 优

本文保留原文的 CDN、DNS、CNAME、回源 Host 和协议回源结构，并根据 HTTP 缓存规范、DNS 规范和当前 CDN 部署实践补充说明。

原文截图已下载到本文同目录的 images/ 文件夹。截图中的服务商名称、界面和网络拓扑属于历史示例，不能代表所有 CDN 厂商的当前实现。

一、什么是 CDN

CDN 的全称是 Content Delivery Network，即内容分发网络。它由分布在多个网络位置的边缘节点组成，通常在用户与源站之间增加一层由 CDN 管理的缓存和代理服务。

用户请求资源时，CDN 会根据域名解析、路由、节点健康状态、容量、网络质量和服务商策略，把请求引导到一个合适的边缘位置。若该节点已有可复用的缓存，就可以直接返回；如果没有缓存或缓存需要重新验证，节点会向源站回源获取资源，再根据缓存规则决定是否保存。

因此，CDN 的核心收益通常包括：

• 减少用户到源站之间的网络距离和跨运营商传输；
• 让静态资源由离用户更近的边缘节点提供；
• 减少重复请求到达源站，降低源站带宽和连接压力；
• 提供 TLS 终止、HTTP/2、HTTP/3、压缩、图片优化等边缘能力；
• 结合 WAF、DDoS 防护、速率限制和访问控制提高网站的可用性与安全性。

但 CDN 不是“把所有内容复制到全球每台服务器”，也不能保证所有请求都更快。动态请求、登录态页面、缓存未命中的首次请求、错误的缓存配置、较慢的源站以及不理想的 DNS 调度，都可能让加速效果变差。缓存个性化内容还可能造成数据泄露，因此必须结合 HTTP 缓存语义和业务特点配置。

CDN 对网络的优化作用

原文总结为“解决第一公里、跨运营商互联、各省出口和骨干网压力”等。这些说法在传统网络环境下有一定背景，但现在更适合表述为：

• 源站出口压力：边缘节点可以吸收大量重复的静态资源请求，减少源站直接出网的流量；
• 访问路径优化：CDN 可能利用多线网络、专用链路、Anycast 或服务商路由优化用户到边缘的路径；
• 热点内容分布：热门文件可以在多个边缘位置缓存，避免所有用户集中访问源站；
• 跨地域容灾：多个边缘和源站入口可以在节点故障时提供一定的故障切换能力；
• 边缘计算：部分 CDN 支持边缘函数、请求改写、鉴权和简单的动态逻辑，减少请求回源。

这些能力是否生效取决于 CDN 产品、套餐、配置和业务流量，不应把“接入 CDN”理解成自动解决所有网络瓶颈。

二、CDN 的基本工作原理

传统访问过程

没有 CDN 时，简化的访问过程如下：

1. 用户在浏览器中输入域名，浏览器、操作系统或本地网络先检查 DNS 缓存；
2. 如果缓存未命中，客户端向递归 DNS 解析器（传统文章常称为 Local DNS）发起查询；
3. 递归解析器可能依次向根 DNS、顶级域 DNS 和权威 DNS 查询，实际查询过程会受到缓存、DNSSEC、DoH/DoT 等因素影响；
4. 权威 DNS 返回域名的 A、AAAA、CNAME 等记录，递归解析器把结果缓存到 TTL 允许的时间；
5. 客户端得到一个或多个 IP 地址后，与目标服务器建立 TCP/TLS 连接，或通过 QUIC 建立 HTTP/3 连接；
6. 服务器处理请求并返回响应。

原文把每次访问都描述为“Local DNS 向 Root DNS 查询，再向授权 DNS 查询”。这只是递归解析器缓存失效时的简化过程。真实环境中大多数查询会命中递归解析器或客户端缓存，不会每次从根服务器重新开始。

使用 CDN 后的访问过程

接入 CDN 后，用户访问的域名通常会通过 CNAME、Anycast A/AAAA 或服务商提供的其他接入方式指向 CDN：

1. 用户查询业务域名，客户端和递归 DNS 解析器先检查缓存；
2. 权威 DNS 返回业务域名的 CNAME，或者直接返回 CDN 使用的 A/AAAA 地址。并不是所有 CDN 都必须使用 CNAME；
3. 递归解析器继续解析 CNAME 链，得到 CDN 的地址。CDN 的调度系统可能根据解析器位置、EDNS Client Subnet（如果可用）、网络线路、节点健康、容量和策略返回结果；
4. 客户端使用域名对应的 TLS SNI 和 HTTP Host 访问 CDN 边缘节点；
5. 边缘节点根据缓存键查找资源：
   • 缓存命中：直接返回仍然可用的缓存响应；
   • 缓存未命中或已过期：按照回源配置向源站请求；
   • 重新验证成功：源站返回 304 Not Modified 时，节点可以继续使用已有响应；
   • 源站返回新内容：节点根据缓存规则保存或转发响应；
6. CDN 将响应返回给客户端，并可能通过 Age、ETag、厂商调试头等信息表示缓存状态。

因此，CDN 对普通用户通常是透明的：用户不需要安装客户端或修改浏览器，只需要通过 DNS 和 HTTPS 证书等配置把域名正确接入 CDN。

“就近节点”不一定是地理距离最近

原文多次使用“离用户最近的节点”。这是一种便于理解的说法，但实际调度不一定只看地理距离：

• 递归 DNS 看到的通常是 DNS 解析器的位置，不一定是最终用户的精确位置；
• 一些解析器会使用 EDNS Client Subnet 提供部分客户端网段信息，但是否支持取决于链路；
• CDN 还会考虑运营商、网络拓扑、节点负载、健康检查、成本和故障策略；
• Anycast 场景下，用户访问的是同一个 IP，具体到达哪个节点由网络路由决定；
• DNS TTL、浏览器缓存和本地递归解析器缓存会让调度结果在一段时间内保持不变。

所以更准确的说法是：CDN 尝试把请求引导到对当前网络条件和策略而言合适的边缘位置，而不是保证物理距离最近。

CDN 网络的组成要素

对于普通 Internet 用户来说，CDN 边缘节点看起来像网站服务器，但它通常还承担了缓存、代理、TLS 和流量调度等职责。

1. DNS 调度或 Anycast 接入

CDN 需要先让用户的域名请求到达合适的边缘入口，常见方式包括：

• CNAME 链接到 CDN 服务商的接入域名，再由 CDN DNS 返回地址；
• 服务商提供 Anycast A/AAAA 地址，让网络路由把请求送到合适的节点；
• 反向代理、专线或云厂商负载均衡等其他接入方式。

原文以 F5 3DNS 为例介绍“智能调度 DNS”。这类系统的核心职责是根据策略返回可用接入位置，并持续采集节点健康、容量和网络状态。现代 CDN 的实现可能由权威 DNS、调度平台、Anycast 路由和边缘控制面共同完成，并不一定存在一个名为“智能调度 DNS”的独立设备。

2. 边缘节点和负载均衡

边缘节点通常包含以下能力：

• 接收 TCP、TLS、QUIC 和 HTTP 请求的入口；
• L4/L7 负载均衡，把请求分配给同一节点内的缓存进程或代理进程；
• HTTP 缓存和缓存键计算；
• 响应压缩、内容协商、Range 请求和连接复用；
• TLS 证书管理、HTTP/2、HTTP/3 和 IPv6 支持；
• WAF、DDoS 防护、访问控制和速率限制（是否提供取决于产品）。

原文提到的 LVS、F5 BIG-IP 和 Squid 可以作为历史上的负载均衡或缓存组件示例。现在的 CDN 通常使用自研或云化的分布式代理系统，具体组件对用户不可见。

3. 内容缓存和共享存储

边缘缓存保存从源站获取的响应。多个边缘节点之间可能通过区域缓存、父节点、Origin Shield 或共享对象存储减少重复回源。

“共享存储”不是所有 CDN 的必需组件：有的 CDN 使用节点本地磁盘，有的使用内存、分布式对象存储或多级缓存。开发者不应假设某个文件一定会永久存在某个节点，缓存会按照 TTL、容量淘汰、主动刷新和服务商策略变化。

4. 源站和源站保护

源站是最终提供内容或动态计算结果的服务器、对象存储、负载均衡器或云服务。CDN 可以把大量静态请求挡在边缘，但缓存未命中、动态 API、刷新请求和鉴权请求仍可能回源。

常见的源站保护措施包括：

• 只允许 CDN 出口 IP 或专用链路访问源站；
• 使用源站鉴权、回源请求签名或 mTLS；
• 不公开源站 IP，避免用户绕过 CDN 直接访问；
• 对源站设置连接数、速率和超时限制；
• 监控回源状态码、回源带宽、缓存命中率和节点错误。

隐藏源站 IP 本身不是完整的安全措施。如果源站地址已经出现在历史 DNS、邮件、证书、错误信息或其他服务中，攻击者仍可能发现它。

三、HTTP 缓存与 CDN

CDN 的“缓存”不是简单地把 URL 对应的字符串保存下来。边缘节点会根据请求方法、目标 URI、Host、查询参数，以及响应 Vary 指定的请求头、Cookie、Authorization 和 CDN 自身配置计算缓存键，并结合响应头判断能否保存和复用。

缓存命中和未命中

一次请求通常可以分为：

• HIT：边缘节点已有可复用响应，直接返回；
• MISS：节点没有响应，需要回源获取；
• EXPIRED/STALE：已有响应但超过新鲜时间，需要回源或重新验证；
• BYPASS/PASS：根据规则不使用缓存，例如带登录态的动态请求；
• REVALIDATED：使用 ETag 或 Last-Modified 验证后，源站确认内容没有变化。

不同 CDN 的响应头名称不同，例如 Age、X-Cache、CF-Cache-Status 等不能跨厂商直接类比。排查时应查看具体 CDN 的文档和调试响应头。

Cache-Control 和 TTL

源站可以通过 HTTP 响应头控制浏览器缓存和共享缓存：

Cache-Control: public, max-age=300, s-maxage=3600
ETag: "asset-v42"
Last-Modified: Tue, 01 Jan 2025 00:00:00 GMT

常见含义：

• max-age=300：响应对一般缓存的新鲜时间为 300 秒；
• s-maxage=3600：对共享缓存（例如 CDN）单独指定 3600 秒，通常优先于 max-age；
• public：明确允许共享缓存保存，在某些默认不确定的场景中有帮助；
• private：响应只应保存在用户私有缓存中，不应被共享 CDN 复用；
• no-cache：不是“不允许存储”，而是使用前必须重新验证；
• no-store：不允许缓存存储响应，适合需要完全避免存储的内容，但不能删除已经存在的旧缓存；
• must-revalidate：响应过期后必须按规则重新验证，不能随意使用过期响应；
• stale-while-revalidate：在重新验证期间允许一定时间内继续提供旧响应，是否支持取决于缓存实现；
• stale-if-error：源站出错时允许在指定时间内提供旧响应，使用前要评估业务一致性和安全性。

CDN 还可能支持 CDN-Cache-Control、Surrogate-Control 或控制台中的 Edge TTL。这些是厂商或生态扩展，使用时要确认它们与浏览器收到的 Cache-Control 如何分别生效。

不要给所有响应都设置很长的 TTL。版本化静态资源适合长缓存：

Cache-Control: public, max-age=31536000, immutable

前提是文件名包含内容哈希或版本号，例如 app.8f3c1.js，更新内容时使用新 URL。HTML 入口和动态 API 往往需要较短 TTL、重新验证或不缓存。

ETag、Last-Modified 与 304

当缓存响应过期时，CDN 或浏览器可以携带验证信息向源站询问：

If-None-Match: "asset-v42"
If-Modified-Since: Tue, 01 Jan 2025 00:00:00 GMT

如果内容没有变化，源站返回：

HTTP/1.1 304 Not Modified

这表示可以继续使用已有响应，不需要重新传输完整响应体。ETag 通常比单纯依赖时间戳更可靠；如果可能，源站可以同时提供 ETag 和 Last-Modified。

哪些内容不应直接缓存

以下内容需要特别谨慎：

• 包含用户个人信息、订单信息或登录态的 HTML；
• 依赖 Cookie、Authorization 或用户权限的 API 响应；
• 带有一次性令牌、验证码或支付信息的响应；
• 响应内容会因请求头变化，却没有正确配置 Vary 的接口；
• 任何未经验证的用户私有数据。

如果缓存键没有包含真正影响响应的因素，可能产生缓存错配或缓存投毒。不要只因为某个响应状态是 200 就把它设置成公共缓存。

四、名词解释

CNAME 记录（CNAME record）

CNAME 是 Canonical Name 的缩写。它把一个 DNS 名称声明为另一个规范主机名的别名。例如：

documents.example.com CNAME docs.example.com

查询 documents.example.com 时，解析器会继续查询 docs.example.com，直到得到 A、AAAA 等最终地址记录。CNAME 的目标是主机名，不是直接填写 IP 地址；正常的正向解析也不是追踪到 PTR 记录，PTR 属于反向 DNS 查询。

CNAME 只负责 DNS 名称解析，不等于 HTTP 请求已经被复制或自动转发。实际 HTTP 请求还会带有 Host，HTTPS 还会使用 TLS SNI；CDN 根据这些信息选择证书、站点配置、缓存和源站。

传统 DNS 中，一个名称配置 CNAME 后通常不能再同时配置其他类型的记录（不同云厂商可能提供 CNAME flattening、ALIAS 或 ANAME 等扩展）。因此根域名 example.com 能否使用 CNAME，要遵循 DNS 服务商的具体能力；不能把普通 CNAME 直接放在所有 DNS 区域的根域名上。

CNAME 域名

接入 CDN 时，服务商通常会为加速域名生成一个接入 CNAME，例如：

www.example.com CNAME customer.cdn.example.net

在 DNS 服务商处添加记录后，访问 www.example.com 的 DNS 查询会进入 CDN 的接入链路。配置完成还需要：

• 在 CDN 控制台添加并校验加速域名；
• 为 HTTPS 配置证书，并确认覆盖用户访问的域名；
• 配置源站地址、回源 Host、回源协议和端口；
• 检查 CNAME 目标没有循环，DNS TTL 和生效时间符合预期；
• 使用 dig、nslookup 或在线 DNS 工具验证 A/AAAA/CNAME 链。

配置示例：

dig +short www.example.com CNAME
dig +short www.example.com A
dig +short www.example.com AAAA

如果业务使用根域名 example.com，应根据服务商提供的方式使用 Anycast A/AAAA、ALIAS/ANAME 或 CNAME flattening。不要仅仅因为 www 子域名可以 CNAME，就假设根域名也可以直接配置 CNAME。

DNS

DNS 即 Domain Name System，是分布式的域名系统。它可以把主机名解析为 A（IPv4）、AAAA（IPv6）、CNAME、HTTPS、MX 等记录，也可以提供其他服务信息。

原文把“域名与 IP 地址一一对应”作为解释，这并不准确：

• 一个域名可以有多个 A 或 AAAA 地址；
• 多个域名可以指向同一个地址；
• CNAME 可以把多个别名指向同一个规范主机名；
• CDN 会根据时间、地域、线路和健康状态返回不同结果；
• DNS 结果会受 TTL、递归解析器缓存和本地缓存影响。

因此，下面的地址只能作为历史示例，不能当作固定映射：

www.example.com -> 192.0.2.10

访问网站时，浏览器和操作系统可能使用本地缓存、企业递归 DNS、运营商 DNS、DoH 或 DoT。解析器完成查询后，客户端还需要通过 HTTP、HTTPS 或 HTTP/3 访问返回的地址。

常见的 DNS 服务商包括云厂商 DNS、Cloudflare、Route 53、DNSPod 等。服务名称、免费额度和功能会变化，选型时应以当前官方文档和业务合规要求为准。

智能 DNS 与 Anycast

原文将 CDN 调度主要描述为“智能 DNS 根据算法返回最近节点”。现代系统还可能使用 Anycast、HTTP 层重定向、全局负载均衡、健康探测和多级缓存。

• 智能 DNS：权威 DNS 根据解析请求来源、线路、区域、节点健康和策略返回不同的答案；
• Anycast：多个网络位置宣告同一个 IP 前缀，由路由系统把用户送往网络上合适的入口；
• 全局流量调度：结合 DNS、Anycast、应用层探测和实时指标选择接入位置。

它们可以组合使用，也可以单独使用。排查调度问题时，不要只查看一次 nslookup 结果就断言“用户一定会访问某个固定节点”。

回源 Host

回源 Host 决定 CDN 向源站发起 HTTP 请求时使用的 Host 请求头，从而选择源站上的虚拟主机。它与“源站地址”是两个不同概念。

例如：

源站地址：203.0.113.10
回源 Host：www.origin.example.com

CDN 可能连接 203.0.113.10，但发送：

Host: www.origin.example.com

这样同一台 IP 上的多个站点就能由 Host 区分。若源站地址本身是域名，CDN 还需要解析该域名得到连接地址；如果使用 HTTPS，TLS SNI 和证书校验名称也可能需要单独配置，不能只修改 HTTP Host。

不同 CDN 对“源站 Host”“回源 SNI”“证书校验名”的配置项命名不同，遇到 421、400、证书不匹配或源站返回错误站点时，应分别检查这几个字段。

协议回源

原文把协议回源描述成“客户端用 HTTPS，CDN 就用 HTTPS 回源；客户端用 HTTP，CDN 就用 HTTP 回源”。这不是所有 CDN 的固定行为，而是一种可配置的回源策略。

现实中可能出现：

客户端 --HTTPS + HTTP/3--> CDN 边缘 --HTTPS + HTTP/2--> 源站
客户端 --HTTPS + HTTP/2--> CDN 边缘 --HTTP/1.1--> 源站

边缘和源站之间可以使用不同的 HTTP 版本，协议也可能由 CDN 配置决定。对于包含登录信息、Cookie、个人数据或管理接口的站点，通常应使用 HTTPS 回源，并正确验证源站证书、SNI 和 Host，避免在 CDN 到源站之间降级为明文 HTTP。

如果源站需要知道用户最初使用的协议，CDN 可能通过 Forwarded、X-Forwarded-Proto 等请求头传递信息。应用应只信任来自可信代理的这些头，不能让客户端任意伪造后改变安全判断。

五、一个完整的 CDN 请求示例

假设用户访问：

https://static.example.com/app.8f3c1.js

完整过程可以简化为：

1. 浏览器检查本地缓存和连接复用状态；
2. DNS 解析 static.example.com，得到 CDN 接入 CNAME 或 A/AAAA 地址；
3. 浏览器通过 TLS SNI static.example.com 与 CDN 建立 HTTPS 上的 HTTP/2 或 HTTP/3 连接；
4. CDN 根据 Host、路径、查询参数和配置计算缓存键；
5. 如果边缘已有新鲜缓存，直接返回 app.8f3c1.js；
6. 如果缓存未命中，CDN 按配置连接源站，并设置正确的 Host、SNI 和回源协议；
7. 源站返回 Cache-Control、ETag 等信息，CDN 按规则保存响应；
8. CDN 将响应返回浏览器，后续请求可能由浏览器缓存或边缘缓存直接满足。

对于带内容哈希的静态文件，可以使用长缓存：

Cache-Control: public, max-age=31536000, immutable

发布新版本时生成新文件名，而不是覆盖同一个 URL。对于 HTML 入口，可以使用较短缓存并在发布时刷新 CDN；否则用户可能拿到引用旧 JS 文件的旧 HTML。

六、CDN 接入和排查清单

接入前

• 确认需要加速的是静态资源、下载文件、视频、网页还是 API；
• 确认哪些响应允许共享缓存，哪些响应必须 private 或 no-store；
• 准备源站地址、回源 Host、回源端口、回源协议和证书配置；
• 确认 DNS 服务商支持所需的 CNAME、根域名接入或 CNAME flattening；
• 为用户访问域名配置正确的 TLS 证书；
• 规划缓存键、查询参数处理、Cookie 处理和刷新策略；
• 限制源站直连，避免用户绕过 CDN；
• 确认 CDN 的 IPv4、IPv6、HTTP/2、HTTP/3、WAF 和日志能力是否符合需求。

出现“访问慢”时

不要只看平均响应时间，可以分层排查：

1. DNS 查询是否慢，是否命中了错误的调度位置；
2. TCP、TLS 或 QUIC 建连是否耗时；
3. CDN 是否 HIT，还是每次都 MISS 回源；
4. 缓存键是否被查询参数、Cookie 或 Host 意外拆分；
5. 源站是否慢，回源连接是否超时；
6. 响应是否被压缩、是否启用 HTTP/2 或 HTTP/3；
7. 节点是否存在丢包、跨运营商绕路或容量问题；
8. 浏览器缓存、Service Worker 和 CDN 缓存是否观察到了不同结果。

可以使用：

# 查看 DNS 链
dig static.example.com CNAME
dig static.example.com A
dig static.example.com AAAA

# 查看响应头和缓存状态
curl -I https://static.example.com/app.8f3c1.js

# 查看完整连接过程（输出可能包含敏感信息，注意脱敏）
curl -v https://static.example.com/app.8f3c1.js -o /dev/null

发布后内容没有更新

常见原因包括：

• 浏览器仍在使用旧缓存；
• CDN 边缘缓存尚未过期；
• HTML 和静态资源使用了过长且不可变的 URL；
• 只刷新了某个区域或某个缓存键；
• 查询参数、Host、Cookie 导致刷新目标与实际请求不一致；
• 源站本身仍返回旧版本；
• 多级 CDN、反向代理或 Service Worker 仍保留旧响应。

优先使用版本化文件名，再把主动刷新作为发布流程的一部分。刷新 API、全站 purge 和按 URL purge 的成本及生效时间可能不同，必须按照服务商文档操作。

总结

CDN 的基本思路是：通过 DNS、Anycast 或其他流量调度方式把用户请求送到边缘节点，由边缘节点按 HTTP 缓存规则直接响应，必要时再回源获取内容。

理解 CDN 时可以抓住这些重点：

• CDN 不只是“离用户近的服务器”，还包括调度、缓存、TLS、代理、监控和源站保护；
• DNS 只负责名称解析，CNAME 不会直接转发 HTTP 请求；
• “最近节点”是网络和策略综合结果，不一定是地理距离最近；
• Cache-Control、s-maxage、ETag、Last-Modified 和缓存键决定了资源是否能安全复用；
• 登录态和个性化内容不能未经设计就放入共享 CDN 缓存；
• CDN 边缘到源站可以使用不同 HTTP 版本，但敏感业务通常应 HTTPS 回源；
• 根域名能否使用 CNAME 取决于 DNS 服务商的 ALIAS、ANAME 或 flattening 能力；
• 缓存、DNS、TLS、回源和源站性能要分层观测，不能只凭一次请求下结论。

参考资料

• RFC 9111：HTTP Caching
• RFC 9110：HTTP Semantics
• RFC 9213：Targeted HTTP Cache-Control
• RFC 5861：HTTP Cache-Control Extensions for Stale Content
• RFC 1034：Domain Concepts and Facilities
• RFC 1035：Domain Names - Implementation and Specification
• MDN：HTTP caching
• Cloudflare：CDN-Cache-Control
• Cloudflare：DNS record types
• GitHub 原文作者文章：5分钟了解CDN加速原理

原文作者：码农突围。商业转载请联系作者获得授权，非商业转载请注明出处。