CDN能缓存视频分片吗？视频加速缓存优化技巧详解
最近总有人问我，CDN到底能不能缓存视频分片？这问题看似简单，背后其实藏着不少门道。搞视频业务的，尤其是做直播、点播平台的，要是没吃透这里面的缓存逻辑，用户体验和带宽成本分分钟教你做人。
先说结论：能，而且必须能。但CDN缓存视频分片，绝不是你扔个文件上去就自动搞定的事。视频文件动辄几百MB甚至几个GB，CDN边缘节点不可能傻乎乎地把整片4K电影都吞下去。这就轮到分片缓存（Chunk Caching）上场了。
视频分片，其实就是把一个大视频文件切成小块（常见的是.ts/.m4s格式的切片）。当用户拖动进度条时，播放器只请求当前需要的那几个分片。CDN节点如果聪明，它不会只缓存用户刚请求的那一个分片，而是会“嗅探”并智能预取接下来可能需要的几个分片。我们去年帮一个直播平台调优，光优化这个预取逻辑，首屏时间就压下去40%，卡顿率直接腰斩。
这里有个坑很多人踩：Range Request（范围请求）的处理。用户拖进度条，播放器发的是类似 “Range: bytes=1024000-2048000” 的请求。有些CDN配置不当，遇到这种请求就只会回源站拿数据，根本不走缓存。结果就是明明热门的视频，每次拖进度条都卡。你得确认CDN服务商是否支持缓存部分内容（Partial Caching），并且正确响应206状态码。实测过某家二线CDN，默认配置下Range Request缓存命中率不到10%，调完参数直接飙到85%以上。
缓存策略怎么定？TTL（生存时间）不是拍脑袋定的。体育赛事直播的分片，可能看完就废，TTL设几分钟都嫌多。但热门网剧的分片，尤其是开头几集，缓存几天都不过分。我们常用的是分层策略：
别忘了HTTP响应头！源站一定要吐对 Cache-Control 和 Expires。见过太多团队在代码里写死max-age=0，还抱怨CDN缓存不住，源站背锅侠实惨。还有 Vary 头，如果你的视频针对不同设备编码（比如手机和TV码率不同），不设 Vary: User-Agent 就等着缓存混乱吧。
进阶玩法是智能预热。比如预测某部剧晚上8点上线会爆，提前把前3集的分片推到全国边缘节点。别傻等用户来请求才缓存，高峰期回源带宽能贵到你肉疼。某短视频平台搞大促前，用脚本模拟请求提前灌缓存，当天带宽费省了六位数。
最后提个隐蔽优化点：分片大小。别以为切片2秒还是10秒无所谓。分片太小，请求次数暴增，TCP握手开销吃掉性能；分片太大，首屏等待时间长，拖动不灵活。实测下来，HLS的2-6秒切片，MPEG-DASH的4-8秒是个甜点区间。还要看具体业务场景——秀场直播切片可以小点，电影点播可以稍大。
搞视频缓存优化，就是跟细节死磕。从分片生成、CDN配置、回源策略到终端适配，链条上每个环节松一点，用户体验就垮一片。下次看到卡顿，别光骂CDN厂商，先看看自己的缓存策略是不是在裸奔。
评论: