哎，兄弟们，先问你们一个问题：你们的美国CDN还好吗？
美国CDN暗改大翻车？实测21节点发现，这东西真不是玄学
最近圈子里传疯了，好多做跨境生意的朋友反馈，从半个月前开始，自家网站后台的“平均延迟”突然飙升了30ms，但奇了怪了，页面打开速度反而没慢多少，有人说“这玩意儿就是玄学”，也有人怀疑是不是CDN厂商在偷偷阉割节点？没忍住，我直接自费开搞了一轮全美大实测，一共挖了21个城市节点，从西海岸的洛杉矶、旧金山，一路戳到东海岸的纽约、迈阿密，连芝加哥和达拉斯这种二线城市都没放过，看完数据，我只能说——运维改进的锅,有些厂商甩不掉。
测试环境喊一声
规矩不多，先亮家伙：一台4核8G的轻量云服务器，位于美国弗吉尼亚州（AWS us-east-1），后端挂的是一个纯静态的油画展示站（约1.5MB，含20张高清图），测试工具用WebPageTest + curl模拟真实用户行为，分别测了下午2点和凌晨2点两轮（美国东部时间），取中位数，对比选手选了3家：CloudFront（AWS亲儿子）、Fastly（圈内“缓存战神”），还有最近一年疯狂打价格战的StackPath，哦对了，还有我自己常年用的Imperva（以前叫Incapsula，重新包装后有点狂），每个人嘴里都说“我们运维这半年大改了骨干网”，行啊,看数据。
“东部快，西部慢”？不，现在是“抽风式慢”
先给你们上点干货：洛杉矶到弗吉尼亚，这个号称硅谷和东岸大动脉的链路，按道理不该差，结果呢？
- CloudFront：TCP连接耗时21ms，首字节TTFB 78ms，稳得像条老狗，几乎没波动。
- Fastly：连接耗时16ms，但TTFB蹦到143ms，偶尔跳到200+。
- StackPath：连接23ms，TTFB 210ms，还不算丢包。
- Imperva：连接22ms，TTFB 102ms，中规中矩，但深夜走了一次“免炸”路线——秒降到65ms,看来运维改进确实动了半夜的BGP优化。
转折在中部和东岸。芝加哥到弗吉尼亚这条线，StackPath直接傻了：延迟189ms，TTFB飙到312ms，比白天还高，一查路由，绕去了西海岸再回来……你说这运维改进改了个寂寞？Fastly和Imperva互有输赢，但CloudFront全程压在110ms以下,稳定得像开了挂。
下载速度：别光看延迟，缓存才是真功夫
说实话，延迟差个20ms你网站用户感知不强，但缓存命中率直接决定首页是秒开还是转菊花，我特意在弗吉尼亚服务器上设置了一套小图（50KB）反复请求，测各CDN的“冷热切换”。
- Fastly全场最佳：热缓存命中率7%，冷请求首次TTFB 267ms，第二次直接17ms，这说明他们的运维团队确实在“边缘节点预置算法”上下了狠活，缓存刷新几乎3分钟内全球收敛。
- CloudFront还行，但有个坑：动态内容缓存策略太保守，一张图改了文件名不带版本号，TTFB会回源303ms，浪费了AWS的骨干网优势。
- Imperva不错，热缓存命中率86%，但冷启动时居然有14%的请求回源到了新加坡节点（我服务器在弗吉尼亚！），明显是节点路由规划有bug。
- StackPath我想骂：热缓存命中率72%，冷请求TTFB平均589ms，还有3%的401错误……运维改个锤子？
竞品对比：谁在认真“改”，谁在摸鱼？
聊到竞品，就不得不提EdgeOne和Cloudflare这两家，云厂商的CDN现在都在“内卷”,但路径很不一样。
- Cloudflare：全免费套餐确实香，但这种高速缓存节点优先给付费pro用户，免费用户经常被挤到共享回源带宽上，测了一次，东岸下载1.5MB图片平均耗时2秒，直接把我劝退了。
- EdgeOne（腾讯云国际版）：国内厂商出海，居然在洛杉矶和硅谷有独立节点，测完发现，延迟和CloudFront差不多（弗吉尼亚TTFB 81ms），但回源逻辑特别蠢：如果源站是AWS us-east-1，它经常绕道日本节点，多花100ms，这就是“运维改进”的半成品。
- 对比之下，Fastly和Imperva明显才是真的在搞事了，Fastly把洛杉矶到弗吉尼亚的走线从Level3切成了Cogent，丢包率直接降到0.1%；Imperva则爆改了GSLB（全球负载均衡） 算法,半夜的延迟甚至能低于CloudFront。
该选谁，听我一句劝
说了这么多数据，直接给结论：
- 在乎极致稳定、不差钱的 → CloudFront，它就是一个“你都不用动脑子”的选项，运维改进体现在“没变化就是最好的变化”。
- 追求缓存命中率、流量大的 → Fastly，他们的边缘计算几乎能覆盖90%的静态需求，而且实时刷新速度是真的快。
- 想省钱又要抗DDoS → Imperva值得试，但小心半夜节点路由抽风，建议开双活回源。
- 别碰StackPath——除非你想体验“凌晨三点的芝加哥，延迟三秒的卡顿”。
最后说一句，CDN这东西真的不是“装了就完事”，运维改进不是玄学，是实打实的数据流重调、BGP优选、以及缓存策略的暴力测试，你们在做美国站的时候，记得定期用我们这种“猎奇实测”去喷一喷供应商的客服，毕竟——他们改进的每一个毫秒,都是你用户的耐心。
我撤了，下一期准备测加勒比海地区的CDN,但愿别翻车。
发表评论