我第一次搞懂 CDN 到底在加速什么

在伦敦住久了，我对“转圈”这件事已经很有耐心了。最典型的一幕是这样的：国内朋友发来一篇博客链接，我点开，标题先出来，图片一张一张慢慢往外蹦，有时候干脆停在那里转圈。我第一反应永远是怀疑宿舍的网，重启路由器、换个时间再试，甚至怀疑过自己的电脑是不是又该清缓存了。后来我把自己的小站也部署到国内的服务器上，从伦敦打开一看，居然也是同样的慢。这时候我才意识到，慢的原因可能根本不是网速不够，而是路太远了。

CDN 这个词，我以前只在各种云产品列表里见过，觉得是那种只有大公司才用得上的东西。真正去了解之后才发现，它的原理其实特别朴素，一句话就能讲清楚：把内容提前放到离用户更近的地方。打个不那么严谨的比方，源站就像一家中央仓库，你每次买东西都要等它从仓库发货；而 CDN 就像在各个城市开了分仓和便利店，常用的货提前铺过去，你下单之后直接从最近的店里拿，自然快得多。这里的“货”，主要是图片、样式表、脚本、视频片段这类不太常变的东西，也就是我们常说的静态资源。

那么，一次访问到底经历了什么呢？我按自己理解捋了一遍，大概是这样：当你在浏览器里输入网址，CDN 会先通过智能调度，判断哪个节点离你最近、状态最好，然后把你的请求引到那个节点上。如果节点里已经缓存了你要的东西，就直接返回给你，根本不用再跑回源站；如果节点里没有，它就先去源站取一份，顺手在自己这里存一份，下一个来访的人就能直接命中了。所以第一次访问某个冷门页面可能还是慢的，但热门内容越被访问就越快，这也是 CDN 很“越用越顺”的原因。

这里还有一个很容易搞混的点：不是所有东西都适合缓存。文章正文、图片、样式可以缓存，但登录状态、购物车、刚提交的评论这些动态内容是不能乱缓存的，否则你可能看到别人的登录信息，或者自己的评论半天不出现。所以接 CDN 的时候，一定要分清楚哪些走缓存、哪些必须回源。这一步想不清楚，后面全是奇奇怪怪的 bug，我自己就吃过这个亏。

为什么跨国访问时 CDN 的效果会特别明显？因为距离带来的延迟是实打实的。数据从伦敦跑到国内的源站，中间要经过很多网络节点，还可能跨运营商、跨海底线路，任何一个环节拥堵都会拖慢速度。CDN 的节点离用户近，相当于把最后这一段长途缩短成了短途，再加上它会根据网络状况选一条相对顺畅的路，体感提升自然就很明显。反过来也一样：如果你的读者主要在国内，而你的服务器在海外，给网站套一层国内节点多的 CDN，也能让国内的打开速度好不少。

说到这里，顺便讲讲我给自己的小站接 CDN 的过程，其实没有想象中复杂。在华为云控制台里，大致就是几步：添加需要加速的域名，填写源站地址，设置一下缓存规则，最后把域名的解析改成 CDN 给的 CNAME 地址。真正花时间的反而是缓存规则的取舍：图片、样式、脚本这些不常变的，可以缓存得久一点；首页和文章页这种可能经常改的，缓存时间就设短一点，不然你刚改完文章，别人看到的还是旧版本。我第一次就栽在这里，改了半天样式死活不生效，最后才发现是缓存没刷新，白白怀疑了半天人生。

还有几个新手很容易忽略的小细节。第一是 HTTPS，最好顺手配好，现在浏览器对非加密站点的态度越来越不友好，CDN 上配证书也没有那么麻烦。第二是缓存刷新和预热：大改版之后记得手动刷新一次缓存，或者把新资源提前推到节点上，不然第一批访客还是要等回源。第三是费用，CDN 大多按流量计费，个人小站的访问量本来就不大，先看清楚计费方式和流量包，别一上来就把所有配置拉满，花了冤枉钱还不知道问题出在哪。

当然，CDN 也不是万能药，这一点我觉得必须说清楚。首先，如果源站本身挂了，节点里那点缓存只能顶一小会儿，不可能一直替源站扛着。其次，登录、支付、下单这类强动态的请求，该回源还是要回源，CDN 加速不了多少。最后，缓存策略本身就是一门平衡的艺术：设得太长，改了东西不生效；设得太短，命中率上不去，等于没加速。还有一点是节点分布要和读者分布对得上，读者都在国内，海外节点再多也帮不上忙；选服务的时候看一眼节点覆盖，比只看宣传里的带宽数字实在得多。控制台里的命中率、流量统计值得经常看一眼，它们会直接告诉你，缓存到底有没有在好好工作。