```html

cdn内容分发网络

2011年春天，我在一家小型视频网站做运维。发网用户上传的容分视频存在杭州机房的一台服务器上，北京的发网用户点开播放，画面要等七八秒才动起来。容分老板天天被投诉，发网我们试过加带宽，容分效果有限——物理距离摆在那儿，发网光信号在光纤里跑，容分杭州到北京往返一次至少20毫秒，发网加上TCP握手、容分TLS协商，发网首屏时间根本压不下来。容分后来有人提议：在联通、发网电信、容分移动的骨干节点各放一台缓存服务器，用户请求先到最近的节点，如果节点上有这个视频就直接返回，没有再去杭州拉。上线一周，北京用户的播放延迟掉到两秒以内。那是我第一次亲手搭CDN，虽然当时还不流行这个叫法。

CDN的本质就一句话：把内容提前搬到离用户更近的地方。这个“近”不是地理意义上的近，而是网络拓扑上的近。你家的宽带接的是哪个运营商，CDN节点就部署在哪个运营商的机房，或者至少是直连的。用户请求一个图片、一段视频、一个JS文件，DNS解析会把他导向一个“边缘节点”，这个节点可能就在同城，甚至同一栋楼里。数据不用跨省、跨网绕圈，延迟自然低。

但“搬内容”三个字听起来简单，做起来全是细节。比如缓存什么？HTML通常不缓存，因为要实时更新；图片、CSS、JS、视频切片缓存时间长，几天甚至几个月。缓存多久合适？太短，回源频繁，源站压力大；太长，用户看到旧内容。我见过一个电商网站把商品详情页的缩略图缓存了30天，结果运营改了主图，前端还是老图，客服电话被打爆。后来他们加了版本号查询参数，?v=20240501，每次更新改一下，CDN自然回源拉新图。这招不优雅，但管用。

回源策略也是坑。假设一个CDN节点上没缓存，它去源站拉。如果同时有100个用户请求同一个文件，节点难道发100次回源？当然不是，它会合并请求，只发一次，其他请求排队等结果。这叫“回源收敛”。但收敛也有代价——如果源站响应慢，所有请求都堵着。我见过一个客户源站用了很重的数据库查询，一个API要跑3秒，CDN节点回源超时设了2秒，结果用户全部看到502。后来他们把超时调到10秒，又加了预热机制，才稳住。

另一个常被忽略的点：CDN不只是缓存静态文件。现在很多CDN支持边缘计算，比如在节点上跑JavaScript，做A/B测试、鉴权、图片裁剪。Cloudflare Workers、AWS Lambda@Edge都是这类。我去年帮一个朋友调他的博客，他用Cloudflare Workers把Markdown在边缘转成HTML，源站只存.md文件。用户请求过来，节点直接渲染，源站流量几乎为零。他说一个月省了十几美元，更重要的是，全球访问速度都差不多快。

不过CDN不是银弹。动态内容、需要实时一致性的数据、涉及用户隐私的请求，通常不走CDN缓存，或者只走CDN的加速通道（比如优化路由、TCP调优），不缓存内容。我见过有人把购物车接口挂到CDN上，结果两个用户看到同一个购物车——灾难。CDN的缓存键默认是URL，但你可以自定义，加上Cookie、Header。加多了，缓存命中率暴跌；加少了，可能串数据。这个平衡点得靠业务经验去摸。

成本方面，CDN按流量计费，便宜的一GB几毛钱，贵的几块钱。乍看不多，但一个日活百万的App，一个月跑几十TB很轻松。我见过一个团队没设缓存过期时间，图片永久缓存，结果用户头像换了，CDN还是老图，他们只好刷缓存，一刷就是几十TB的回源流量，账单直接翻倍。所以缓存策略得定期review，别设完就不管。

最后说个观察：CDN这个行业，技术门槛在降低，但运维门槛在升高。以前自己搭节点、调BGP，现在云厂商一键开通。但怎么配缓存规则、怎么设回源超时、怎么监控命中率和回源率，这些活儿越来越细。我见过太多人开了CDN就不管了，直到源站被打挂或者账单爆炸才回头看。CDN像水电，用的时候没感觉，出问题的时候全是大事。

一个简单的判断：如果你网站的用户分布超过三个省，或者有静态资源超过100KB，就该考虑CDN了。别等用户骂慢才动手。

```

很赞哦!（97583）