CDN Range：为什么视频大文件会让CDN头疼？
验证与回滚
说到CDN Range，很多问题都出在细节上。当你用手机刷一个1080P的教学视频，或者在公司内网下载一个几百MB的安装包时，背后的CDN（内容分发网络）承担了巨大的压力。普通的小文件（比如图片、CSS）可以整块缓存，但视频文件动辄几十MB甚至几个GB，如果CDN节点每次都要完整缓存整个文件，不仅占用大量存储空间，还会导致首次访问时用户等待很久（因为要等源站传完整个文件）。更糟糕的是，用户可能只看到视频的前30秒就关掉了，但CDN已经白白浪费了后半段的带宽。这就是视频大文件分发需要特殊技术的原因。
补充参考：此处可内链到“CDN Range故障排查实例”。
分片缓存：让CDN只缓存用户真正需要的那一段
Range Requests 是什么？
HTTP协议中有一个功能叫做Range Requests（范围请求）。简单说，就是客户端（比如浏览器或播放器）可以在请求时告诉服务器：我只要这个文件从第X字节到第Y字节的那一段数据。服务器收到后，只返回那一段，同时响应状态码206 Partial Content。对于视频播放而言，用户拖动进度条到第10分钟，播放器就会发起一个Range请求，只获取第10分钟对应的字节范围。
CDN如果支持Range Requests，就可以按需缓存分片：当第一个用户请求视频的前30秒时，CDN从源站获取文件的前几兆字节，缓存下来；第二个用户请求第2分钟到第3分钟时，CDN再去获取对应范围，再缓存。这样CDN节点的存储不会被整个大文件占满，而只存储用户实际访问过的那些“热点分片”。
分片缓存的优势
- 减少源站负载：分片越小，CDN回源请求越精确，源站不必传输整个文件。
- 提升首次缓存效率：用户只下载当前需要的那一小段，首屏加载时间大大缩短。
- 节省带宽和存储：无人访问的分片不会被缓存，避免了资源浪费。
需要留意的陷阱
分片缓存也不是完美无缺。如果分片颗粒度太小（比如每1KB一个范围），CDN会创建大量碎片文件，管理开销增大。通常视频平台会结合分片大小与码率来设计，比如按2秒或5秒的视频时长切分一个分片（对应固定字节范围）。另外，如果CDN节点上的分片过期策略设置不当，可能导致用户反复回源获取同一分片，反而增加延迟。
边缘预热：在用户访问之前把数据推送到CDN节点
为什么需要预热？
即使有了分片缓存，用户的第一次请求仍然需要回源——虽然只回源少量分片，但回源过程依然有网络延迟。对于直播回放、热门视频、短视频平台的开场片段，我们希望用户在点击瞬间就能获得数据，零等待。这时就需要边缘预热（Preload / Prefetch）。
边缘预热的意思是，在用户实际请求之前，由CDN主动从源站拉取指定的内容（可以是整个文件，也可以是指定的某个范围），并缓存在边缘节点上。这样当用户发出请求时，数据已经在节点上，直接返回，避免了回源时间。
预热如何与分片缓存配合？
对于视频大文件，我们不一定要预热整个文件。比如一个30分钟的视频，我们可以只预热前30秒或前1分钟（即视频的开头分片），因为大多数用户会从头开始观看。预热结束后，用户点击播放时，开盘片段直接从边缘节点响应，几乎零等待；后续的进度拖动再依赖分片缓存按需拉取。这种策略称为热点分片预热。
另外，你也可以预判用户行为：比如在视频平台首页推荐视频，可以在流量高峰前批量预热那些推荐视频的开头分片。CDN通常提供API或控制台来提交预热任务，指定URL和范围参数（如Range: bytes=0-1048576）。
关联教程：此处可内链到“CDN Range部署与验证”内容。
调优实践：让分片缓存与预热发挥最大效果
1. 确认CDN和源站都支持Range Requests
这是基础。源站（如Nginx、Apache）默认支持Range，但有些对象存储需要特殊配置。CDN厂商通常也支持，但需要开启“分片缓存”或“切片缓存”功能（不同厂商叫法不同）。检查方式：用curl -I -H "Range: bytes=0-100"测试源站返回206，再测试经过CDN后是否也返回206。
2. 合理设置分片大小
分片大小取决于视频码率和播放器行为。一般建议分片覆盖2~10秒的播放时长。比如一个2Mbps码率的视频，2秒对应500KB，可以设置为512KB一个分片。分片太大则失去细粒度优势，分片太小会增加请求数量。可以通过CDN控制台调整切片阈值（如阿里云CDN的“切片大小”参数）。
3. 配置缓存过期时间
分片缓存同样需要设置Cache-Control max-age。由于视频的热度随时间下降，可以设置较长过期时间（比如7天）配合主动刷新。对于需要即时更新的内容（如直播回放），设置较短的过期时间（如10分钟）再结合预热。
4. 制定预热策略
- 时机：内容发布前30分钟或流量高峰前1小时。
- 范围：只预热开头1~5个分片，以及可能被推荐跳转的关键时间点（如中间精彩片段）。
- 批量：利用CDN的预热API一次提交多个URL，注意控制并发数避免触发源站限流。
5. 监控与调优
通过CDN访问日志或实时监控，关注回源率和分片缓存命中率。如果某个视频的分片缓存命中率低（比如低于80%），说明分片设置可能不合理，或者预热范围偏小。同时观察首字节时间（TTFB）：预热后的首字节时间应该接近0（从边缘节点直接返回）。
延伸阅读：此处可内链到“CDN Range配置案例”相关文章。
想继续深入：此处可内链到“CDN Range优化清单”文章。
总结：用最小成本换取最大加速效果与CDN Range
我的处理经验
视频大文件分发不必追求“全量缓存”或“全量预热”。通过分片缓存（Range Requests），你可以让CDN只缓存用户实际消费的内容，节省存储和带宽；通过边缘预热，你可以针对最热门的分片主动拉取，消灭首次访问的等待。两者结合，既能保证播放的流畅性，又能管理好成本。对于小白来说，理解这两个核心概念，就能明白为什么很多视频平台表面“丝滑”，背后其实是HTTP协议和CDN工程智慧的巧妙配合。
当你下一次配置CDN时，不妨先检查：是否开启了切片缓存？预热任务是否只指向了开头几个分片？做好这两步，你的视频分发质量会有肉眼可见的提升。按这个顺序复查，CDN Range遇到异常时也更容易定位。
延伸阅读