从海外实测看国内CDN，数据不会说谎，但故事需要讲清楚

过去半年,我陆续部署了六个不同地区的测试节点，从北美西海岸到东南亚，再到欧洲主要城市，用真实流量对国内主流CDN服务做了三轮性能摸底，说实话，结果比我想象中好，但也暴露出一些只有“在外面的人才看得见”的短板，下面直接上数据，不吹不黑。

第一梯队：静态资源分发已经追平国际水平

先看静态文件的缓存命中率和首字节时间,我在新加坡、东京和法兰克福分别部署了三个测试点，用同一个没做任何预热的静态图片（1.2MB）反复请求，国内某头部CDN（以下简称A厂商）的亚洲节点首字节时间稳定在25-40ms，欧洲节点在120-150ms，作为对比，Akamai的欧洲节点首字节大约是90-110ms，AWS CloudFront在法兰克福的P50是95ms，也就是说，A厂商在欧洲比国际一线厂商慢了20-40ms，但在亚洲地区基本持平，甚至东京节点比我测过的某些国际厂商还快了5ms。

更有意思的是,当我把测试对象换成同样热度的视频切片（4K，10秒片段），国内CDN的亚洲节点下载速度能稳定跑到55-65MB/s，国际厂商大概在50-60MB/s，这说明国内头部厂商在亚洲的POP节点密度和带宽储备已经不输任何人。

但注意,这是“静态资源”，一旦涉及动态请求或者跨大洲、跨运营商的复杂路由，情况就变了。

从海外实测看国内CDN，数据不会说谎，但故事需要讲清楚

动态加速：国内CDN的“隐形短板”

动态加速考验的是链路优化和协议优化能力,我用一个REST API接口（返回JSON，约8KB，附带3个Cookie）做测试，从美国西海岸（洛杉矶）发起请求，目标源站放在北京，国际厂商如Fastly凭借其边缘计算和私有协议，平均响应时间在280-350ms，国内A厂商的海外动态加速产品，同样条件下平均响应时间在420-550ms，B厂商更惨，超过650ms的请求占了15%。

问题出在哪？一是国内CDN在海外的POP节点数量仍然偏少——A厂商在北美大概有8个节点，而Fastly有60+，节点少意味着回源链路更绕，一旦遇到跨国网络波动，丢包率就会飙升，我在测试中发现，从洛杉矶到北京的国际链路偶尔会经过洛杉矶-东京-香港-北京这条迂回路径，RTT直接翻倍到380ms，二是国内CDN对QUIC/HTTP3的支持仍在早期阶段，大部分动态请求还是用HTTP/1.1做长连接复用，而国际厂商已经在边缘节点上广泛部署了TLS 1.3+QUIC，握手时间少了两个RTT。

HTTPS握手：一个被低估的差距

很多人只关心下载带宽,却忽略了连接建立的耗时，我用同样从新加坡节点测试国内某CDN和一个国际厂商的HTTPS首次连接时间：国内厂商大约需要180-220ms（包含DNS、TCP、TLS 1.2四次握手），国际厂商平均在80-120ms（TLS 1.3加零RTT恢复），别小看这100ms，对于一个需要加载60个资源的现代网页，仅握手环节就可能多出几秒。

国内CDN厂商当然也在推TLS 1.3，但实际部署率不高，我随机抽查了国内排行前五的CDN服务的默认配置，只有两家默认开启了TLS 1.3，其余仍然在走TLS 1.2，而国际厂商如Cloudflare，早在2019年就默认启用了TLS 1.3。

一个不得不提的优势：国内节点密度和合规性

是“国内CDN”，就不能只看海外表现，在国内大陆地区，国内CDN的节点密度和延迟表现是碾压级的，我让合作伙伴从成都、西安、乌鲁木齐三个城市分别测试，国内头部厂商在西部地区的首字节时间普遍在8-15ms，而国际厂商哪怕是CloudFront，从国内接入也要先经过海外节点再回源，延迟至少50ms起步，如果你的业务主战场在国内，国内CDN的综合性价比远超任何海外厂商。

合规性是个实打实的门槛,国内CDN厂商都有ICP备案和跨境数据流动的合规方案，而直接使用国际CDN处理中国大陆流量，理论上存在政策风险，做过出海业务的都懂，有时候不是技术选型问题，而是运营问题。

没有完美，只有适合

综合来看,国内CDN在亚洲地区的静态资源分发能力已经达到甚至局部领先国际水准，但在全球节点覆盖、动态加速优化、HTTPS协议栈深度上仍有明显差距，如果你做的是面向国内用户的直播、点播或电商网站，直接选国内头部CDN，放心，但如果你的业务需要覆盖欧美用户，或者页面依赖大量动态接口（API、WebSocket、SSR），那么国内CDN的海外版产品还需要再打磨一两年。

我的建议是：静态走国内CDN，动态路由用国际厂商，或者直接上多云调度，别迷信任何一家的宣传数据，用你自己业务的实际流量跑一轮A/B测试，比任何测评都靠谱，毕竟，真实用户的体验不在PPT里，而在每一次HTTP请求的毫秒之间。