CDN 分片预取 Prefetch，流媒体业务开启与关闭的权衡

、CDN 分片预取 Prefetch 功能业务背景

大部分商用 CDN 具备分片预取 Prefetch 功能：当用户请求某一个 TS 分片，CDN 预判播放顺序，主动回源提前把后面几个分片预先拉取到 CDN 边缘节点，用户后续请求分片直接命中边缘缓存，降低回源，提升首帧、分片加载速度。

很多新手看到预取可以提升性能，直接全部业务打开预取功能。但是预取不是万能增益，在直播、DVR 时移、多码率、用户快速拖拽 seek 跳转场景，预取反而会带来副作用：回源 QPS 暴涨、大量无效预取分片，源站带宽压力飙升。

预取的收益和代价需要权衡，点播和直播业务的策略配置完全不一样。调试预取带来的异常，我会使用 m3u8live.cn，结合 CDN 日志，观察分片请求序列，区分是真实用户请求还是 CDN 预取产生的回源。

二、Prefetch 预取能带来什么，会带来什么副作用

✅正向收益：

❌负面副作用：

三、不同业务场景配置建议

普通点播业务（用户大多顺序观看，拖拽不多）

可以适度开启预取，预取分片数量不要配置过大，例如预取 2‑3 个分片即可，不要配置预取 10 个以上。

HLS 直播业务、DVR 时移回看业务

不建议开启分片预取。用户可能回看、跳转，预取产生大量无效回源，抬高源站带宽与 QPS 开销。直播 M3U8 本身会滚动淘汰分片，预取收益有限，副作用明显。

多码率 Master 自适应业务

谨慎开启预取。切换码率会触发多套分片预取，回源压力上涨。如果要开启，预取数量调小。

四、高频踩坑现象

坑 1：所有业务一刀切全部打开预取，直播 DVR 也开启，源站 QPS 暴涨

点播少量用户，源站回源请求量远大于真实用户在线数，大量请求来自 CDN 预取，不是真实浏览器用户。

坑 2：预取数量配置过大，一次预取大量分片，源站带宽打满。

坑 3：测试环境看不出问题，线上真实用户大量拖拽跳转，无效预取才暴露。测试环境用户都是顺序播放，预取看上去效果很好。

五、排查实操步骤

第一步，业务 M3U8 粘贴网页调试工具，观察浏览器真实分片请求顺序。 第二步，核对 CDN 访问日志，区分真实客户端 IP 与 CDN 内部预取回源请求。如果回源数量远高于真实在线用户，评估预取带来的无效请求占比。 第三步，点播、直播分开配置预取策略，直播 DVR 优先关闭预取。

六、总结

CDN 分片预取 Prefetch 可以在用户顺序播放时提前缓存分片，优化播放体验，但不是所有业务适合开启。直播、DVR 时移、多码率业务开启预取，会因为用户拖拽跳转产生大量无效回源，抬高源站 QPS 和带宽。点播可以适度小数量开启预取；直播 DVR 优先关闭预取。借助网页调试工具观察真实浏览器分片请求，结合 CDN 日志，评估预取带来的收益和副作用，合理配置预取开关与预取数量。