视频和下载站为什么慢？CDN分片缓存与Range

视频拖动卡顿、下载断点续传出问题，多半与Range请求和缓存分片策略有关。本文解释边缘节点如何按字节区间取内容、分片大小为何影响回源量，并给出四项运营侧可调的优化。

做视频站和下载站的人常遇到一种怪现象：首页打开很快，但视频一拖动进度条就卡，或者大文件下载走到一半速度骤降。这类问题八成不在带宽总量，而在取字节的方式上。 要理解它，先看一个请求头：Range。播放器拖动进度条时并不会重新下载整个文件，而是告诉服务器只要第 150 到 250 兆这段字节。支持该能力的服务器返回 206 Partial Content，并在响应头里标明返回的是哪一段。下载工具的断点续传、安装包的增量更新、播放器的快速起播，全靠这套机制。 CDN 边缘节点因此要做一件比较麻烦的事：把客户端要的零碎区间，变成对源站的一次次请求，再把结果组装回去。这里的分片策略直接决定体验和成本。 传统做法是按固定分片切文件。分片设得小，源站会被大量小请求打满，节点还要在内存里合并这些碎片；分片设得大，客户端只要几兆，节点却可能回源拉走一大块，多出来的流量在源站和节点之间来回搬运，用户可能早就退出播放了。更麻烦的是分片大小往往写在缓存键里，中途调整会导致缓存整体失效。 近一年主流 CDN 的做法在往按存储块对齐的方向演进：节点本来就把文件按固定大小的块存在磁盘上用于支持断点下载，回源时也直接按块取，节点内部再按客户端要的字节区间裁剪响应。这样过取仍然存在，但上限被固定住了，不再取决于运营人员拍脑袋设的分片参数。对使用方来说，结论很直接：选 CDN 时可以问一句“Range 请求怎么处理、分片是不是可调”，答案能反映这家节点的实现成熟度。 除了等厂商升级，运营侧有四件事可以自己做。 一是切片要合理。HLS 用短分片能加快起播，但分片过短会让请求数暴涨，通常几秒一片比较平衡，并与关键帧对齐。 二是热门文件提前预热。新上的剧集、版本包在上线前推到边缘，避免首波用户全打到源站。 三是缓存键要干净。URL 后面挂随机参数、时间戳、用户标识，等于让每个请求都无法命中，缓存形同虚设。 四是关注回源带宽而不只是总带宽。回源打满时，用户侧带宽再大也没用。 加速IDC 的 CDN 加速服务覆盖东南亚 12 个节点，支持大文件分片缓存与 Range 请求，视频、下载、独立站这类静态内容为主的业务可以先小流量灰度，再按实际命中率调整策略。