就近服务：物理距离就是延迟
光速再快也跑不过物理：北京到广州一个 RTT 就有 30ms，跨境 200ms 起步，中间还要过一堆路由器。CDN 的思路简单粗暴：把内容复制到全国乃至全球几百个边缘节点，用户访问的永远是离他最近的那台。静态资源 RTT 从 200ms 压到 10ms 以内，这就是“快到离谱”的全部秘密——不是传输更快了，是路变短了。
DNS 调度：怎么把用户引到最近的节点
接入姿势（CNAME 方式）：
cdn.example.com CNAME → example.com.w.kunlunsl.com
（CDN 的调度域名）
用户查 cdn.example.com
→ 本地 DNS 追 CNAME 查调度域名
→ CDN 的智能 DNS 根据请求来源 IP 判断地理位置/运营商
→ 返回「离他最近、最快」的边缘节点 IP
→ 用户与边缘节点建连，命中缓存直接返回注意调度依据是本地 DNS 的出口 IP，不是用户真实 IP——用户配了个偏远的公共 DNS，可能被调度到别的城市。App 用 HttpDNS 能把这事做准，正好接上一篇的劫持话题。
回源：边缘没有怎么办
边缘节点缓存 miss，就向上一级（区域中间层，L2）要，L2 也没有才回源站（你的服务器）。两级结构的意义：L2 汇聚大命中率，把回源压力收敛到个位数比例，源站不至于被全国几百个边缘节点同时敲门。回源时 CDN 会带 X-Forwarded-For、Host 等头，源站日志里别看见奇怪 IP 就报警。命中率怎么算：命中请求数 / 总请求数，静态站点 95% 是及格线，掉到 80% 就该查缓存配置了。
缓存策略：你说了算的部分
# 源站响应头就是给 CDN 和浏览器的指令
Cache-Control: public, max-age=31536000 ← CDN 和浏览器缓存一年
Cache-Control: private, no-store ← 个人数据，谁都不许存
Cache-Control: public, max-age=60, s-maxage=86400
↑ 浏览器 60 秒，CDN 缓存 1 天（s-maxage）
# 命中验证：内容变了怎么办？
# 方案 A：改动 URL —— 文件名带内容 hash（主流做法）
# app.a3f8c2.js → app.9d41e0.js 旧文件自然过期，无刷新问题
# 方案 B：主动刷新 —— CDN 控制台提交 URL/目录刷新（有配额，救急用）
# 发布后预热：主动把新资源推到边缘，避免第一批用户回源踩踏回源风暴与动态加速
两个进阶话题。回源风暴：一个超热点文件缓存恰好过期，几百个边缘节点同一秒全回源，源站瞬间被打爆——解法是预热 + 合理的过期时间错峰 + L2 汇聚（同文件多个边缘只回源一次）。动态内容加速：接口响应没法缓存，但 CDN 的骨干网优化（专用线路、链路优选、连接复用）依然能压缩传输 RTT，这就是全站加速（DSA）产品卖的东西。记住边界：能缓存的交给 CDN，不能缓存的优化链路，别指望 CDN 替你优化数据库。下一篇：长连接复用——把握手和慢启动的成本摊薄的完整账本。
评论 (0)