1. 实测背景与整体思路1.1 为什么拿博客类站点做CDN评测先说结论CDN不是万能的但选对了场景收益可以非常直观。这次我花了大概两周时间拿一个内容结构和访问特征都跟CSDN技术博客很接近的文档站做了360CDN的缓存命中率与跨网加速实测。为什么选这类站点因为技术博客站点的内容形态太典型了——大量静态页面、图片、JS/CSS资源用户分布在全国各地而且往往是“白天上班摸鱼刷帖、晚上回家继续刷”的访问节奏峰值和低谷的差距极大。这类站点最头疼的问题就两个一是源站带宽被静态资源打爆二是跨网访问延迟高得离谱。我那个测试站之前在别的CDN上跑缓存命中率常年徘徊在85%左右图片资源有时候甚至不到70%说白了就是大量请求直接穿透到源站日志里刷得满满的全是静态资源请求。这次换到360CDN主要就是想看看它在命中率优化和跨网调度这两块到底能不能解决实际痛点。1.2 评测方案设计不能只看一个数字做CDN评测最忌讳的就是上来就跑个压测工具拿一个“平均响应时间”就下结论。缓存命中率这个东西不同的统计口径能差出10个百分点跨网加速效果更是跟测试节点的位置强相关。所以这次我设计了四组对照实验静态资源缓存效果图片、CSS、JS三种资源类型分开统计命中率动态与静态请求混合场景模拟真实用户浏览页面的完整请求链路同运营商访问与跨网访问对比电信用户访问电信节点、电信用户访问联通节点高峰期与低峰期缓存行为变化观察缓存淘汰和回源压力每个场景都跑了至少3轮每轮持续1小时取均值作为最终数据。中间还故意穿插了一些“冷门文章”的访问——就是那种一个月都没人看的页面——来测试缓存冷启动的表现。后面我会逐个拆解这些数据。1.3 前置条件与测试环境测试站点的基本情况先交代清楚项目配置源站架构Nginx PHP单机8核16G源站带宽独享20Mbps静态资源占比页面请求约40%图片/JS/CSS约60%日均PV真实流量约5万压测时额外叠加测试节点华北电信、华东联通、华南移动、西南电信各1个需要说明的是20Mbps的源站带宽很“逼仄”如果CDN命中率上不去压测一上来源站就会被打满这反而能更明显地暴露问题。我也在源站Nginx上加了log_format专门记录回源请求方便统计真实的回源量和回源耗时。提示如果是做正式评测建议先把源站的访问日志结构整理好至少能区分出静态资源请求、动态请求和回源请求否则后面做数据归因时会非常痛苦。2. 缓存命中率核心指标拆解与实测配置2.1 命中率的两种口径别被厂商页面忽悠先理清一个基本概念CDN控制台里显示的“命中率”不一定是你以为的那个命中率。我这次同时关注两个指标——请求命中率和流量命中率。请求命中率指的是CDN节点直接响应用户请求、不需要回源的请求次数占比流量命中率则是CDN节点直接返回的流量占总请求流量的比例。这两个数字往往不一样而且差异可能很大。比如一个页面里有一张大图2MB和一堆小图标每个2KB请求命中率可能是小图标刷上去的但流量命中率才是真正决定“源站带宽压力”的关键。360CDN控制台里这两个指标都有展示但我建议自己从回源日志里再算一遍——厂商指标的统计窗口和口径不一定跟你的场景完全匹配。我实测下来静态资源为主的页面360CDN的流量命中率能达到95%以上但请求命中率会因为动态请求的存在被拉低到90%左右。如果你的站点动态请求比例高别一看请求命中率“不高”就慌先分清口径再说。2.2 360CDN缓存规则的配置要点360CDN的缓存策略配置在“缓存配置”模块里核心是“缓存规则”和“缓存优先级”两块。不同类型的资源要配不同的规则我按下面这套配的# 图片类资源缓存时间设置较长 location ~* \.(jpg|jpeg|png|gif|webp)$ { expires 30d; add_header Cache-Control public, max-age2592000; } # JS和CSS版本化文件可以开长缓存 location ~* \.(js|css)$ { expires 7d; add_header Cache-Control public, max-age604800; } # HTML页面建议短缓存兼顾内容更新 location ~* \.html$ { expires 10m; add_header Cache-Control public, max-age600; }不过在360CDN控制台配置时我遇到的第一个坑是它默认对HTML文件的缓存策略偏保守需要手动在“缓存规则”里新建规则把.html后缀的缓存时间从默认的“不缓存”改成10分钟。如果忘了配页面会频繁回源命中率直接被拉低好几个点。第二个坑是缓存优先级。360CDN支持“全局缓存规则”和“路径缓存规则”叠加后者的优先级默认更高。我当时配了一个全局的“所有文件缓存30天”又单独给/api/路径配了“不缓存”结果是/api/目录下的动态接口确实没被缓存但静态资源如果路径里带了/api/字样也会被误伤。所以配置路径规则时一定要用具体的后缀匹配而不是目录匹配除非你确认该目录下完全没有静态资源。2.3 我实测得到的缓存命中率数据先上数据再解释原因。连续一周的观测结果取了稳定后的均值资源类型请求命中率流量命中率备注图片(jpg/png/webp)96.8%98.2%老文章图片体积大收益明显CSS/JS93.5%91.7%存在部分未带版本号的旧文件HTML页面78.2%82.4%短缓存策略动态化程度较高整站综合92.4%95.6%按请求量和流量加权计算图片资源的命中率最高原因是图片变更频率极低几乎可以视为永久缓存。CSS/JS稍低一点主要是有一些历史遗留文件没有带版本号每次发布新版本时URL不变CDN只能靠缓存时间到期后回源重新拉取。HTML页面命中率最低一方面是缓存时间本身设得短另一方面是我测的那段时间在持续改版页面内容频繁变动。整个站点的综合流量命中率95.6%比我之前用的CDN高了大约7个百分点。别小看这7个百分点按每天100GB的CDN流量来算意味着每天能少回源约7GB——对源站来说这7GB如果全走回源相当于一天要多扛好几个小时的20Mbps满负荷。注意如果CDN命中率偏低先不要急着怀疑CDN厂商90%的情况是缓存规则没配好或者源站响应头里带的Cache-Control字段有问题。检查源站的响应头比什么都管用。2.4 缓存未命中的真实原因排查这轮测试里我特意追踪了一批缓存未命中的请求把原因整理成了四类第一类是“首次访问”也就是缓存冷启动。一个老文章平时没人看突然被首页推荐了第一个用户的请求必然回源。这类占比大概5%属于正常现象不用处理。第二类是“缓存过期”占比最多。我测了一个未设置长缓存策略的JS文件缓存时间只有默认的2小时一篇文章被频繁访问时每2小时就要回源一次。解决思路很明确所有静态资源文件在发布时都该带上版本号或hash值然后放心大胆地开30天以上缓存。第三类是“缓存Key匹配失败”这是最隐蔽的坑。360CDN默认的缓存Key包含URL参数如果同一个URL带不同的query参数会被当成不同资源缓存。比如/logo.png?v1和/logo.png?v2哪怕实际返回的文件内容完全一样CDN也会分别缓存、分别回源。如果页面里引用的静态资源URL带了动态参数建议在“缓存Key设置”里忽略这些参数否则命中率会被明显坑掉。第四类是“源站响应头不兼容”。当你源站返回的Cache-Control是no-store或private时CDN会严格遵循不缓存该资源。我排查时发现有个接口被意外加上了no-store头导致每次请求都回源去掉后就正常了。3. 跨网加速表现多线路实测与数据对比3.1 跨网问题到底出在哪国内网络环境下跨网访问的延迟问题几乎是无解的“物理题”。电信和联通之间的骨干网互联带宽有限移动和电信/联通之间的互联质量也时好时坏。一个典型场景源站放在电信机房联通用户访问时请求要跨骨干网走一圈RTT往返时延可能在50~100ms如果赶上晚高峰丢包和拥塞还会让实际体验更差。CDN的跨网加速思路本质上就是“绕路”——把内容提前分发到离用户最近的节点上让流量尽可能在同运营商内部完成传输。360CDN的做法是自己建设了覆盖电信、联通、移动三大运营商的节点集群通过DNS调度把不同运营商的用户指向各自运营商内的节点。听起来简单实际效果如何得看数据和真实用户感受。3.2 同网与跨网的延迟实测对比我分别在华北电信、华东联通、华南移动三个点用脚本定时发起请求记录DNS解析耗时、TCP连接耗时、TLS握手耗时和首字节时间TTFB每小时一轮持续3天。核心数据整理如下测试场景平均TTFB(ms)平均连接建立(ms)首包送达稳定性电信用户→电信CDN节点289非常稳定联通用户→联通CDN节点3512稳定移动用户→移动CDN节点3211稳定电信用户→联通CDN节点(模拟跨网)6821偶发抖动源站直连(电信服务器/联通用户访问)8726晚高峰波动明显直接说结论同运营商接入CDN节点后TTFB基本都能控制在35ms以内和直连源站相比提升非常明显。跨网场景比如电信用户被调度到了联通节点虽然比同网要慢一些但仍然优于直连源站——68ms对比87ms体验差距还是很明显的。不过这里要提一个实际观测到的问题360CDN的DNS调度结果并不是100%精准的。比如华东联通节点的测试机偶尔会被解析到电信节点上导致跨网访问。虽然比例不高大约8%~10%的请求但一旦出现延迟就会明显上升。这可能跟测试时段、节点负载均衡策略有关也跟本地DNS缓存污染有关系。这种情况不是360CDN独有其他CDN厂商也有类似现象。3.3 移动端弱网环境的加速表现做技术博客类站点移动端流量其实是大头——很多人是拿手机刷文章的。我又加测了移动4G网络环境下的表现用的策略是拿一台4G随身WiFi作为网络出口通过模拟抖动和丢包的方式对比直连源站和走360CDN的差异。移动4G环境下直连源站的下载速度波动非常大峰值和谷值能差出5倍以上尤其晚高峰时段加载一张1MB的图片可能要等5秒以上。走360CDN之后同样的图片平均加载时间从3.2秒降到了0.9秒而且速度波动明显平缓了。原因不难理解CDN节点离用户近TCP连接的关键往返握手、TLS协商走的是“短链路”受骨干网拥塞的影响就小。这里还有一个容易忽略的细节TLS握手耗时的占比。在移动弱网下一次完整的HTTPS请求里DNS解析TCP握手TLS握手可能要占掉总耗时的一半以上。CDN节点离用户近每次握手的RTT从80ms降到20ms省下的时间非常可观。我测试时特意统计了HTTPS请求的握手耗时直连源站平均162ms走360CDN后平均47ms。3.4 大文件分发的跨网表现我的测试站里有些文章配图是2~5MB的高清截图这个体量在网络环境差的时候很能考验CDN的传输能力。我测试了一个4.6MB的PNG图片在不同线路下的完整下载时间网络环境直连源站下载耗时360CDN下载耗时提升幅度电信宽带3.8s1.1s71%联通宽带5.2s1.3s75%移动4G7.6s1.6s79%移动宽带(晚高峰)9.4s1.8s81%移动宽带晚高峰场景下的提升最夸张接近81%。原因也很好理解直连时流量要跨网传输骨干网拥塞会导致TCP拥塞窗口频繁收缩下载速度上不去而CDN节点内容已经在本地运营商网络内拥塞概率大幅下降。需要说明的是这个测试结果跟“源站与测试节点的相对位置”关系很大。如果你的源站本来就在移动机房那移动用户直连的效果可能也不错CDN的优势主要体现在跨网场景。4. 深度排查与问题修复实录4.1 缓存不生效响应头的“隐藏杀手”在测试过程中最让我头疼的一个问题是明明在360CDN控制台里配置了“图片缓存30天”但部分图片的命中率就是上不来。抓包一看源站返回的HTTP响应头里带了Cache-Control: no-cache。这个no-cache不是“不缓存”而是“缓存前必须先回源验证”——语义上跟no-store完全不同。但很多CDN为了安全起见会把no-cache当作“不缓存”处理或者每次请求都回源做条件请求验证。我查了源站Nginx配置发现有一个全局的add_header Cache-Control no-cache规则它在某些路径下覆盖了更具体的缓存配置导致CDN拿不到明确的缓存授权。解决办法是把源站响应头理顺静态资源的响应头尽量手动指定public, max-age2592000这类明确值同时避免在Nginx的location里重复设置Cache-Control头。一个请求经过多层代理时响应头只会保留最后一道代理设置的值配置冲突很难排查。4.2 缓存刷新与预热的正确姿势站点改版时免不了要刷新CDN缓存。360CDN的刷新API很好用但我第一次用的时候差点翻车——我一次性提交了2万个URL的刷新请求结果大概有30%的URL刷新失败控制台提示“刷新URL数量超出单次限制”。后来才摸清它的限制单次URL刷新上限是1000条目录刷新上限是10条具体数值可以看控制台说明。处理大量URL刷新时正确的姿势是写脚本分批提交每批500~800条间隔几秒再提交下一批。我写了个简单的Shell脚本#!/bin/bash # 按行读取URL列表每500条为一批调用API刷新 while read -r url; do count$((count 1)) batch$batch$url\n if [ $count -ge 500 ]; then # 调用360CDN刷新API具体参数见官方文档 curl -X POST https://cdn.api.example.com/refresh \ -H Authorization: Bearer $API_TOKEN \ -d typeurlurls$batch count0 batch sleep 3 fi done urls.txt刷新之外更推荐的做法是做“预热”。如果你的站点有大版本更新提前把核心页面的URL通过预热接口提交给CDN让它在用户访问前主动回源拉取内容。预热后的内容首次被访问时命中率为100%能避免“发布后第一批用户集体回源”的阵痛。4.3 动态内容与静态缓存的冲突处理技术博客站点除了文章之外还会有一些“半动态”内容——比如文章浏览量、评论数、用户登录状态。这些内容如果在页面HTML里直接渲染会导致整页不能被缓存这是很多站点的通病。更好的方案是“动静分离”把浏览量、评论数这类实时性要求不太高的数据改成页面加载后通过AJAX接口异步拉取或者用ESLEdge Side Include这类技术把页面拆成静态部分和动态部分静态部分交给CDN缓存动态部分实时回源。我跟测试站的朋友讨论过这个问题他之前就是被浏览量拖累了缓存命中率——去掉之后首页的HTML命中率从55%升到了78%。另一个常见问题是登录态Cookie。如果CDN把带有Cookie的请求也当作动态请求处理命中率会被大幅拉低。稳妥的做法是通过配置让CDN忽略静态资源请求里的Cookie静态资源不需要区分用户只对HTML页面保留Cookie感知。360CDN的“缓存忽略Cookie”开关就是干这个的。4.4 回源策略优化与故障演练这次实测还意外验证了360CDN的“源站故障切换”能力。测试过程中我故意把源站的Nginx停掉模拟源站宕机。观察到的现象是已经缓存的资源不受影响CDN节点正常返回未缓存的新请求出现5XX错误但大约30秒后部分请求被CDN自动导向了备用源站。整个切换过程没有人工干预说明360CDN的源站健康检查机制是有效的。但要注意如果你的源站本身是单点CDN的故障切换也只能解决“缓存层”的可用性动态接口和未缓存内容依然会失败。所以在做CDN加速的同时源站的高可用同样不能忽视。我还发现一个配置上容易忽视的点360CDN回源时默认使用HTTP/1.1如果你在源站开了HTTP/2回源性能并不会因此提升。但回源连接复用Keep-Alive一定要确认开着否则每个回源请求都要新建TCP连接源站的并发连接数会成倍上涨严重时会被连接数打挂。5. 实战调优建议与避坑清单5.1 缓存配置的“黄金法则”经过这轮实测我总结了几条适合技术博客/文档类站点的缓存配置经验直接照着抄就行资源类型缓存时间是否忽略参数优先级图片(jpg/png/webp)30天忽略高CSS/JS(带版本号)30天忽略高CSS/JS(不带版本号)7天不忽略中HTML页面10分钟不忽略低API接口不缓存--注意事项有三点第一所有静态资源务必带版本号或hash发布这是长缓存的前提第二图片文件如果存在“同一URL内容更新”的场景比如用户头像建议改用独立的URL或者加版本号而不是缩短缓存时间第三HTML页面缓存时间要跟你的内容更新频率匹配——技术博客一般10分钟就够新闻类站点可能需要更短。5.2 监控告警别等用户吐槽了才发现很多用了CDN的人有个错觉CDN是“别人家的服务”出了问题CDN厂商会兜底。实际上CDN的接入层错误、缓存命中率骤降、回源失败这些问题如果自己不配监控很可能等大量用户反馈之后才发现。这轮测试里我给监控配置提几个具体建议在源站Nginx日志里增加$upstream_response_time字段做“源站回源响应时间”的监控正常应该在200ms以内如果持续超过500ms大概率是CDN节点在恶性回源。利用360CDN控制台或API拉取“回源带宽”和“命中率”数据按小时粒度做趋势图。命中率突然下降5个百分点以上通常意味着缓存规则被误改或者源站的Cache-Control头出了问题。如果条件允许部署一套独立的拨测系统从多个城市模拟用户访问核心页面监控可用性和性能。CDN是否宕机拨测最直观。我这次测试过程中就设置了一个简单的拨测脚本每5分钟请求一次首页并记录状态码和耗时。有一段时间发现华东地区的拨测成功率掉到了85%排查下来是当地某CDN节点出现了过载自动切换后恢复——没有监控的话这个问题可能要等真实用户投诉才会被发现。5.3 安全防护缓存与防攻击的平衡CDN除了加速之外一般还承担着一部分安全防护职责。360CDN也有WAF、CC防护、DDoS防护相关的功能。但要注意安全策略和缓存策略之间可能存在冲突。比如开了“人机验证”功能后如果验证请求不能正常通过会导致部分用户连静态资源都加载不出来。我实际测试中遇到过一个问题开了CC防护后某些高频率刷新的用户比如我们自己的爬虫脚本的请求被拦截导致页面数据显示异常。最后在CC防护规则里加了白名单才恢复正常。所以安全配置建议从“宽松”到“严格”逐步收紧每个阶段观察对正常用户的影响不要一上来就拉满强度。另外HTTPS证书的配置也要留意。360CDN支持免费证书和自定义证书但如果你的站点使用的是特定证书体系比如某些企业内部的证书链要确认CDN节点回源时的TLS配置是否兼容否则会出现用户访问正常、但回源失败的诡异问题。5.4 成本与性能的平衡技巧CDN的计费模式通常是“按流量”或“按请求数”计费360CDN两种模式都有。技术博客类站点图片流量占大头请求数相对少按流量付费更划算。但有一个容易被忽略的成本陷阱缓存命中率低的时候回源流量虽然不计入CDN流量费但会占用源站带宽。如果源站在云上回源流量本身也要花钱这部分成本往往被忽略。从成本角度考虑把图片压缩、WebP转码这类工作放在发布流程里做比单纯靠CDN硬扛要省钱得多。我测试站里的图片之前在源站是没有做压缩的后来接入了WebP转码整体流量下降了约35%CDN费用和源站带宽成本都跟着降了一截。CDN的“图片处理”功能缩略图、格式转换、质量调整在很多场景下可以直接替代源站的图片处理服务减少源站负载。5.5 迁移与灰度验证的实操建议如果你正准备从其他CDN迁移到360CDN或者正在纠结要不要换给你几个实操建议先在测试品牌下接入一个低优先级的域名比如test-cdn.yourdomain.com配置好之后让测试团队和核心用户通过修改本地Host的方式访问测试域名验证功能正确性。同时跑一遍我前面说的四组对比实验拿到数据后再决定是否全量切换。迁移时域名解析的TTL尽量提前调低到300秒这样切解析的时候生效更快。还有一个容易忽视的坑是跨CDN迁移之后源站的防火墙和访问白名单需要同步更新。CDN服务商的回源IP段各不相同如果你源站做了IP白名单限制忘记加新CDN的回源IP会导致全站回源都失败。这属于“迁移事故高发区”一定要提前确认。最后分享两个小技巧第一个是关于缓存Key的“URL参数忽略”功能。我一开始以为这是个无关紧要的选项实际测下来才发现技术博客站点里很多图片URL会带上一些统计参数比如?fromhome、?utm_sourcexxx如果这些参数不忽略同一个图片会被缓存成N份既浪费存储又降低命中率。建议把所有静态资源的URL参数都设置为“忽略”但动态接口千万不要忽略否则用户数据会串。第二个是关于“回源Host”的设置。如果你在CDN上配置了多个域名共用同一个源站一定要确认回源Host设置正确。否则CDN回源时会带上默认的源站Host头可能导致源站路由错误或SSL证书不匹配。这个配置错了表现往往是“页面打不开”或者“证书报错”但排查起来却很容易忽略CDN层。我在这上面吃过一次亏花了半天才找到原因。这轮360CDN的实测做下来我的总体感受是它的缓存规则配置灵活度够用命中率调优的空间大跨网加速表现对技术博客类站点来说提升很直观。如果你正纠结于CDN选型或者想优化现有CDN的命中率希望这篇文章能给你一些可落地的参考。每个站点的内容结构、用户分布、源站能力都不一样建议拿真实业务场景跑一轮数据再决定毕竟纸面参数再好不如实测数据来得实在。