什么是 CDN？静态网站为什么都爱用它

上一篇聊建站选型的时候提到过，静态站生成之后是部署到静态托管平台上的，而这类平台背后基本都依赖 CDN 做加速分发。这篇就单独聊聊 CDN 是什么、解决了什么问题。

一个最直观的问题：物理距离

假设一个网站的服务器物理上放在某个特定城市的机房里，一个用户从很远的地方访问这个网站，数据要跨越很长的物理距离才能到达用户设备。距离带来的直接后果是延迟——哪怕网络本身没有任何拥堵，光在光纤里跑一个来回也需要时间，距离越远，这个时间成本越高。

如果只有一台服务器、放在一个固定地点，那么离这台服务器物理越远的用户，访问速度天然就会越慢。CDN（Content Delivery Network，内容分发网络）要解决的核心问题就是这件事：把内容尽量”搬”到离用户更近的地方。

CDN 是怎么做到的：边缘节点

CDN 服务商会在全球各地的数据中心部署大量服务器，这些分布在各处的服务器统称”边缘节点”（Edge Node）。当你的网站接入 CDN 之后，内容不再只放在你自己那一台源服务器上，而是会被复制一份缓存到离用户最近的边缘节点上。

用户发起请求时，CDN 会通过 DNS 或者 Anycast 之类的路由技术，把请求引导到地理位置或者网络路径上”最近”的那个边缘节点，而不是一路打到大老远的源服务器。这个节点如果已经缓存了用户要的内容，直接就近返回，用户几乎感觉不到延迟；这个过程叫”缓存命中”（Cache Hit）。

如果节点没有缓存怎么办：回源

边缘节点不可能提前缓存互联网上所有的内容，如果用户请求的内容在这个节点上还没有缓存（“缓存未命中”，Cache Miss），节点会转头去问源服务器要这份内容，这个动作叫”回源”（Origin Pull）。拿到内容之后，节点会一边把结果返回给用户，一边把这份内容缓存下来，方便后续同一份内容的请求可以直接命中，不用每次都跑一趟回源。

回源这件事也是为什么”第一个访问某个内容的用户”体验上可能会比后来的用户慢一点点——因为他撞上了缓存未命中，多绕了一圈去源服务器取数据。

缓存多久：跟 DNS 的 TTL 是同一个思路

CDN 节点上的缓存同样有过期时间，通常由 HTTP 响应头里的 Cache-Control、Expires 这些字段控制，服务器可以针对不同类型的内容设置不同的缓存策略：

• 图片、字体、打包好的 JS/CSS 这类”内容基本不会变”的静态资源，可以设置很长的缓存时间，甚至配合文件名里带的哈希值实现”内容变了文件名就变、旧缓存永远不失效也没关系”
• HTML 页面这类可能经常更新的内容，缓存时间通常设得短一些，或者干脆配置成每次都回源验证

这跟前面写 DNS 那篇提到的 TTL 本质上是同一套思路：缓存时间设得越长，命中率越高、性能越好，但内容更新之后生效也越慢，需要根据内容本身的变化频率去权衡。

静态网站为什么天生适合上 CDN

静态站生成出来的产物就是一堆纯文件——HTML、CSS、JS、图片,内容在构建完成之后就是固定的,不会因为不同用户访问而产生不同结果。这个特性和 CDN 的缓存机制可以说是天作之合:

• 因为内容对所有用户都一样,同一份缓存可以服务给所有人,缓存命中率天然就高
• 没有动态渲染、没有数据库查询,边缘节点直接把缓存好的文件返回就行,不需要请求穿透到源服务器执行任何计算
• 大部分现代静态托管平台(Cloudflare Pages、Vercel、Netlify 这些)本身就是”CDN + 静态托管”绑在一起的产品形态,部署即自动接入全球节点,不需要额外配置

对比之下,一个需要动态渲染、每个用户看到的内容都可能不一样的网站(比如带登录状态的应用),CDN 能帮上的忙就有限得多——至少页面主体内容这部分很难简单地”缓存给所有人共用”。

CDN 顺带解决的另一个问题:防护和抗压

CDN 除了加速,还顺带带来了一层防护效果。因为用户的请求先打到分布在各地的边缘节点、而不是直接暴露源服务器的真实地址,一定程度上能隐藏源站信息,也能把突发的大流量(不管是正常的访问高峰还是恶意的攻击流量)先在边缘节点这一层分摊掉一部分压力,减少直接打到源服务器上的冲击。这也是为什么很多网站接入 CDN 除了图性能,也有安全层面的考量。

小结

CDN 本质上做的事情很朴素:把内容尽量放到离用户更近的地方,减少数据跑的物理距离,顺带靠大量缓存分担源服务器的压力。对于静态网站这种”内容固定、人人看到的都一样”的场景,CDN 几乎是最契合的搭配——这也是为什么现在几乎所有静态站教程,最后一步都是”部署到某个自带 CDN 的静态托管平台”,而不是自己找一台服务器裸跑。