同样的网站有的用户秒开有的用户转圈半天同样是晚高峰视频平台就是不卡小型网站却直接白屏。如果你也被这类问题困扰过那问题的答案大概率藏在CDNContent Delivery Network内容分发网络里。CDN的核心逻辑其实很简单别让所有用户都挤到你那一台服务器上而是把内容提前放到离用户足够近的地方让访问请求在半路就被“消化”掉。这篇博文我会从CDN的底层工作原理讲到它带来的实际价值顺便拆解一道华为机考常考的“CDN分发服务器选址”算法题最后聊聊Cloudflare、国内免费CDN等落地选型以及我接入CDN后踩过的几个坑。适合刚接触CDN的开发者、运维同学也适合正在准备大厂面试的工程师对照理解。1. 先从一次访问慢说起没有CDN时请求是怎么走的1.1 一条HTTP请求的真实路径假设你的网站部署在华东某机房用户在北京、广州、新疆同时访问。没有CDN时他们的请求都会沿着公网链路一路跑到源站服务器。这里面就有两个问题一是物理距离带来的延迟光信号在光纤里传播是有速度上限的每1000公里怎么也有几十毫秒的往返时延再加上中间路由器逐跳转发、排队实际延迟只会更高二是跨运营商互联瓶颈用户是联通宽带源站却在电信机房请求要跨运营商绕一圈高峰期丢包率能到百分之几甚至更高。我做过一次实测源站放在上海电信分别用北京联通、广东移动的宽带去访问延时基本都在40ms到70ms之间看起来不算夸张但一旦页面里有几十个静态资源每个请求都要经历TCP握手、TLS握手、请求响应几个来回用户感知到的加载时间会被放大到好几秒。问题从来不是单次请求慢而是页面资源数量多、链路长把慢累积成了卡。1.2 关键瓶颈动态资源和静态资源共享一条链路更扎心的是很多小网站把API请求、HTML页面、图片、CSS、JS全部放在同一个域名下、同一台服务器上。动态API确实必须回到源站计算但图片、脚本这类静态资源完全没必要每次都由源站输出。结果是一次并发访问高峰甚至可能只是某张图片被某个社区热帖引用服务器带宽就被占满了真正需要计算能力的API也跟着变慢。CDN解决的就是这个结构性矛盾把静态资源缓存到全网分布的边缘节点上让用户从最近的节点拿数据源站只处理动态请求和缓存未命中的部分。理解了这个分工后面所有的原理都好懂了。2. 从域名到节点CDN是怎么把用户引到“最近”的2.1 CNAME和全局负载均衡指路牌怎么立起来接入CDN后你做的第一件事通常是把自己的域名CNAME到一个CDN服务商提供的域名上比如cdn.example.com.cname.cloudcdn.net。用户发起访问时DNS解析到这个CNAME后会进入CDN服务商自己搭建的全局负载均衡系统GSLBGlobal Server Load Balancing。GSLB不是一台服务器而是一套分布式DNS集群。它收到解析请求时会看两个信息一是用户使用的Local DNS服务器所在地这决定了调度精度通常能到市级二是各边缘节点的实时负载、链路质量、健康状态。然后它把离用户最近、而且当前不忙的节点IP返回给用户。这里有个常见的认知误区GSLB调度的依据是“Local DNS的位置”不是“用户终端的实际位置”。如果用户用了非本地的公共DNS调度结果可能不是最优的这一点在排障时要记住。2.2 边缘节点命中与回源链路用户拿到边缘节点IP后请求就到了CDN的边缘服务器。边缘节点收到请求先查自己的缓存如果缓存里有且未过期直接返回如果没缓存或者缓存已过期它就要“回源”——也就是去你的源站把数据取回来存到缓存里再返回给用户。这就是CDN最基本的生命周期用户 → 边缘节点 → 缓存 → (未命中) 源站 → 边缘节点 → 缓存 → 用户。回源的过程中边缘节点和源站之间还会做条件请求If-Modified-Since / ETag校验源站返回304时边缘节点继续用本地缓存并在TTL允许范围内延长缓存时间源站返回200时说明内容确实变了边缘节点更新缓存。这个机制决定了CDN缓存更新的节奏后面讲“改版不生效”时会详细说。2.3 TTL、缓存键与缓存策略命中率是CDN的命根子CDN的价值几乎等同于缓存命中率。命中率高回源次数少源站压力小用户延迟低命中率低CDN就只是多了一跳中转不但没加速反而变慢。影响命中率的核心是缓存策略这里有三件事要搞清楚TTL生存时间缓存内容在多长时间内被视为有效。热门图片设个7天没问题但版本化的JS/CSS如果文件名不变、TTL太长就很容易出现改版不生效的惨案。缓存键Cache Key默认情况下URL就是缓存键。但同一个URL如果因Cookie、Authorization头、查询参数不同而返回不同内容就需要把缓存键设置得精细一点反过来如果两个URL指向同一份资源可以用“忽略查询参数”这类规则合并缓存提高命中率。缓存规则CDN服务商一般允许你按目录、文件后缀、URI模式、请求头设置缓存策略比如/static/*缓存30天、*.html缓存5分钟、/api/不缓存。我在实践中最常见的错误是把所有文件一刀切地设置成“缓存1天”结果图片脚本全都没吃到长时间的缓存红利回源量巨大还有一种是把动态HTML也缓存了7天线上数据改了页面不更新用户投诉一波接一波。正确做法是分类型精细化设置而不是笼统设置。3. 不只是加速CDN在峰值和高可用上的底层价值3.1 用边缘缓存扛住突发流量没有CDN时你的源站带宽决定了你能承受多少并发。假设服务器带宽是10Mbps一个页面500KB理论上能同时支撑的请求数非常有限。一旦遇到营销活动、热点新闻、社区传播流量瞬间上来源站很可能就挂了。CDN的防护作用在于绝大多数请求在边缘就被返回了打不到源站源站只需要处理很小的回源流量。印象比较深的一次经历是朋友的小电商站上了某平台的秒杀入口瞬间冲进来几万用户抢首页静态资源全部命中CDN源站只扛了每秒几百个API请求最终稳稳度过。从那以后我做系统设计时默认都会把“静态资源走CDN”作为基础配置。3.2 节点级别的容灾与故障转移CDN是分布式系统单点故障对整体影响很小。某个边缘节点宕机GSLB会把它从调度列表里摘掉新请求自动切换到旁边的健康节点某个运营商线路出问题调度系统也会优先绕开。这种能力是分布式架构天然带来的——当你有几百上千个节点时任何一个节点的故障都可以被其他节点吸收。但对于源站CDN还能起到一层“缓冲”作用即使源站短暂不可用只要边缘节点缓存还在用户的静态资源请求依然能正常返回。源站宕机期间网页的“壳子”HTML如果在缓存中和静态样式还能渲染出来至少比白屏强得多。当然如果HTML也做了CDN缓存那么源站恢复后要注意主动刷新缓存不然用户会一直看到“假死”的旧页面。3.3 HTTPS、WAF与DDoS缓解安全能力是附带红利绝大多数商业CDN都会在边缘节点上终结TLS会话替你完成证书部署和HTTPS握手。这意味着用户的TLS握手是在就近的节点完成的不用跨越半个国家去找源站TLS握手时延大幅降低。源站和CDN节点之间的回源链路则可以用内部HTTPS证书或专线保护。CDN还天然是DDoS防护的合适位置。攻击流量到达边缘节点时CDN可以识别异常请求、限速、拦截把攻击分散到整个网络消化掉源站几乎感知不到。很多云厂商的CDN还内置了WAF规则可以拦截SQL注入、XSS攻击、恶意爬虫。这些能力对中小企业来说特别划算——不需要自己买高防不需要单独部署WAF接入CDN就顺带获得了一部分基础安全能力。4. 华为真题视角“CDN分发服务器选址”到底在考什么4.1 问题本质最小化“用户到最近服务器”的距离成本搜索“CDN分发服务器选址”会看到不少华为机考真题的讨论这类题的典型描述是给定一棵树或一张图共有n个节点每个节点有用户数量或权重要求选择k个位置部署CDN服务器使得所有用户到“最近CDN服务器”的距离通常按路径长度乘以节点权重计算之和最小。有些变体还会要求每个用户只能访问归属区域内的服务器或者服务器有容量上限。这道题剥离掉“CDN”的业务外壳后本质是一个经典的设施选址问题Facility Location Problem在树形结构上可以通过动态规划精确求解。之所以面试官喜欢拿它出题是因为它既考察了建模能力又考察了树形DP的转移设计还能顺便聊聊真实CDN节点部署的工程考量。4.2 树形DP思路状态设计是关键假设题目给的是带权树w[u]表示节点u的用户数量目标是选k个点作为CDN服务器最小化所有节点加权到最近选中点的距离和。常见的做法是树形DP状态设计如下dp[u][j][0/1]表示以u为根的子树中共选择了j个CDN服务器且u点本身是否部署了服务器时子树内所有节点到它们各自最近服务器的加权距离贡献的最小值。但这里有个难点子树中某个节点的“最近服务器”可能不在子树内部而在子树外。处理这种跨子树依赖通常需要引入“最近选中祖先”之类的额外维度或者用换根DP配合贪心处理。如果题目拆解得比较简单也可以先预处理出任意两节点之间的距离然后用分组背包的思路做“子树内选j个点”的合并。这里我给出一个相对通用的树形DP转移框架伪代码仅供参考具体要看题目数据范围:def dfs(u, parent): # 初始化u子树内选0个或1个服务器u本身作为服务器的代价 dp[u][0][0] w[u] * depth[u] # 如果外部有服务器距离暂时按到根距离算换根时再修正 dp[u][1][1] 0 for v in adj[u]: if v parent: continue dfs(v, u) merge(dp[u], dp[v])实际机考时更常见的是简化版本先把问题转化为“求每个节点到当前候选服务器集合的最短距离”再用贪心或DP迭代求解。如果是二分答案还可以转成“能否用k个服务器覆盖所有节点且每个节点的最近服务器距离不超过mid”这又变成了树上的最小支配集问题也可以用贪心判断。4.3 从真题到真实规划算法题背后的工程维度华为这道真题虽然抽象但背后的工程逻辑是真实的。真实CDN节点规划时除了“距离最近”还要考虑权重不是人数而是流量一个购物中心的带宽需求可能远超一个大型居民区选址时按“峰值流量×单用户平均请求数”加权更合理。节点容量有限边缘服务器不是无限带宽的当多个区域同时涌向同一个节点时需要容量维度上的约束这时候真题里的“容量上限”变体就更接近现实。成本与覆盖的平衡节点越多覆盖越好但成本和运维复杂度也越高。真实规划往往是在预算内选出“性价比最高”的一组节点而不是理论最优解。链路质量与容灾两个节点之间物理距离近网络不走直线还要看骨干网拓扑、运营商互联质量。这些都是算法题里不会写、但真实世界里必须考虑的因素。所以说这道真题的价值不只是练DP它其实是让你用一个算法题去体会CDN规划的本质矛盾资源有限需求分散怎么放才能让全局体验最好。准备面试的同学能在讲解法时顺便说出这层工程映射是很加分的。5. 落地选型商业CDN、国内免费CDN和Cloudflare怎么选5.1 CDN计费模式和“免费”的真实成本选CDN前先要搞清楚计费方式。主流厂商基本都是“流量计费 请求数计费 增值服务计费”流量按GB阶梯计价超出部分越来越便宜请求数通常百万次起步收费HTTPS请求、动态加速、WAF、日志服务等都要单独加钱。还有一些厂商提供“95峰值带宽”计费模式适合流量稳定的视频、下载类业务但波动大的网站慎选因为峰值计费对毛刺流量非常不友好。所谓的“免费CDN”常见有几种云厂商的新用户免费额度、限时限量的免费套餐、以及面向个人站长的永久小额度免费服务。免费额度一般都有两个前提一是实名认证二是只适用于静态加速且品牌标识甚至强制跳转公告页等方面会有约束。做商业项目时别把免费额度当主力方案它更适合个人博客、演示站、学习项目。5.2 国内免费CDN的现状七牛、又拍云、腾讯云EdgeOne等如果你在国内、目标用户也在国内国内CDN的节点覆盖自然是最好的。就我接触过的免费额度方案七牛云早期有对象存储和CDN的免费额度适合个人博客存放静态资源但对未备案域名限制较多且免费额度的有效期和总量要留意官方调整。又拍云长期有“免费云CDN”的认证活动完成实名认证后可以申请每月有免费流量和免费HTTPS请求额度个人开发者用起来相对舒服只是认证流程略繁琐。腾讯云EdgeOne腾讯云的一体化边缘安全加速平台新用户有一些免费流量包覆盖CDN、DDoS防护、WAF、边缘函数等能力适合想要“一站式”的同学。其他云厂商阿里云、百度智能云等的CDN也都有各自的新人试用额度但到期后需要转为付费用之前先看续费价格。这里要特别提醒一个国内服务绕不过去的问题域名备案。国内CDN节点要求源站域名已完成ICP备案否则无法正常接入。个人开发者如果域名没备案可以考虑优先用云厂商的海外节点或者直接用下面要说的Cloudflare。5.3 Cloudflare CDN个人站长的老朋友Cloudflare 是全球覆盖范围最广的CDN服务商之一免费套餐就能提供基础CDN加速、自动HTTPS、DDoS防护、WAF基础规则对个人站长和小型项目来说非常友好。接入方式也简单在Cloudflare添加站点按提示修改域名的NS记录等待生效即可。免费版还能一键启用“始终使用HTTPS”、配置页面规则、设置缓存级别功能比很多商业CDN的入门版还丰富。但要说客观存在的体验差异Cloudflare免费版的节点绝大多数部署在海外中国大陆用户访问时请求会先绕到境外节点再回源到国内服务器或海外服务器。这个链路在部分区域、部分运营商的体验尚可但夜间高峰和跨洋链路易出现波动。如果你的目标用户以中国大陆为主建议优先考虑国内CDN如果是面向海外用户或者个人博客、开发者工具站这类对大陆访问要求不高的场景Cloudflare的免费套餐非常值得用。我自己就有个面向海外读者的技术博客用Cloudflare免费版配置了自定义缓存规则后全球加载速度提升明显而且被DDoS打的时候也基本无感。个人博主、开源项目文档站用它几乎是零成本换取稳定和安全。6. 接入CDN后必须处理的三个工程细节6.1 改版不生效缓存规则和刷新机制的博弈接入CDN最常见的翻车场景是线上改了CSS或JS刷新浏览器却还是旧样式。原因基本都出在缓存策略上——CDN边缘节点缓存了旧文件TTL还没到自然不会回源取新内容。解决办法有两个层面。第一源头层面静态资源的文件名带上版本号或内容哈希比如app.8f3a2b.css每次发布都生成新文件名这样CDN眼里它就是“新URL”自然要重新回源。这是目前前端工程化的标配做法谁用谁知道。第二运维层面每次发布后用CDN控制台或API执行“刷新缓存”把指定URL或目录下的缓存强制失效。刷新有生效时间一般几十秒到几分钟大目录全量刷新更慢所以不要指望刷新能救急根本解法还是版本化文件名。执行刷新后我习惯再验证一下用curl -I看响应头里的CF-Cache-StatusCloudflare或X-Cache其他厂商确认是否已变为MISS并检查Last-Modified和ETag是否已更新。这套验证流程看着简单但能避免“以为刷新了、其实没刷干净”的尴尬。6.2 动静分离与回源策略的取舍CDN默认只对静态资源友好动态API如果强行走CDN反而会因为多一跳中转而增加延迟。好的实践是把动态请求的域名直接指向源站或走动态加速通道静态资源单独用一个子域名比如static.example.com、img.example.com接入CDN。这样做还有一个好处动态域名的Cookie不会随着图片、CSS请求一起传出去既减少了请求体积也降低了安全风险。至于回源策略重点在“回源HOST”的设置上。CDN回源时用哪个域名去源站请求必须和源站Nginx/Apache的站点配置对上。我遇到过的一个坑是CDN控制台里回源HOST配成了源站域名A但服务器上的虚拟主机配置只认域名B回源请求全部404页面图片大面积裂开。排查了很久才发现是回源HOST不匹配把配置对齐后瞬间恢复。这个细节很多文档不会强调但接入时一定先确认清楚。6.3 HTTPS证书与回源证书校验接入CDN后用户和CDN之间的HTTPS由CDN的证书体系负责但CDN和源站之间的回源链路同样需要考虑安全。通常有三种做法HTTP回源CDN到源站走明文配置简单但隐患很大中间链路可能被窃听或篡改不建议在生产环境用。HTTPS回源校验源站证书CDN回源时像浏览器一样校验源站证书安全等级高但需要源站的证书链完整、不过期否则会回源失败。HTTPS回源不校验证书CDN仍然加密回源但不校验源站证书。适合源站证书频繁变动或自签证书的场景但要承担一定风险。个人实践建议源站能配免费证书就配用Let‘s Encrypt或云厂商的免费证书都行然后把CDN回源方式设为“HTTPS 校验证书”。这样整条链路都是加密的安全性最有保障。如果源站是IP直接访问、无法绑定域名的场景再退而求其次用“不校验证书”的方式。结尾我踩过几次坑之后的心得回头看我第一次接入CDN的经历真是把能犯的错都犯了一遍缓存规则一刀切、改版后不刷新、回源HOST配错、证书过期导致回源失败。但恰恰是这些坑让我把CDN的原理彻底想明白了——它不是一个黑盒而是一套“调度 缓存 回源 安全”的完整体系。如果你也是刚开始接触CDN我建议不要急着配一大堆规则先把默认配置跑起来用浏览器开发工具看看到底哪些请求命中了缓存哪些在回源命中率是多少。CDN服务商控制台里一般都有缓存命中率报表盯两周数据再根据实际状况调规则。这样折腾一轮下来你对CDN的理解会远超“打开开关就好了”这个层面。最后再分享一个小技巧接完CDN后记得在源站的安全组或防火墙里只允许CDN回源IP访问源站端口这能让你的源站从公网上“隐形”起来少挨很多扫描。