CDN 如何实现视频加速？有哪些关键技术？

CDN 如何实现视频加速？有哪些关键技术？

CDN 视频加速的核心思路：把视频切片、多码率编码、缓存在离用户最近的边缘节点，播放时根据网络状况动态选择码率和分片，从而降低首屏时间、减少卡顿。

一、自适应码率（ABR）

播放器实时检测带宽和缓冲区水位，动态切换码率档位。主流 ABR 算法分三类：

• 基于缓冲区：缓冲区低选低码率，充足选高码率，实现简单但反应慢
• 基于吞吐量：用近期下载速率预估带宽，选不超过带宽的最高码率，反应快但波动大
• 混合算法：同时参考缓冲区和吞吐量，BOLA 和 MPC 是工业界常用方案

追问：ABR 切换时为什么会出现画面模糊再清晰？
因为切换发生在分片边界，中间需要等当前分片播完才能请求新码率分片，这段时间画面保持旧码率。

二、视频编码优化

编码格式	相比 H.264 体积	编码速度	兼容性	典型场景
H.264	基准	快	最好	通用点播
H.265	小 50%	慢 3-5x	较差	高清/带宽受限
AV1	小 60%	极慢	有限	未来/超高清

生产中通常生成多码率多分辨率版本（码率阶梯），编码参数重点控制：GOP 大小（关键帧间隔）、maxrate/bufsize（码率上限）、帧率（动态场景 60fps，静态 24fps）。

三、流媒体协议：HLS vs DASH

HLS（Apple 主导）：m3u8 播放列表 + .ts 分片，生态成熟，iOS 原生支持。
DASH（MPEG 标准）：mpd（XML）+ .m4s 分片，跨平台，灵活度更高。

两者都能跑在纯 HTTP 上，天然适配 CDN 缓存。CMAF 格式让 HLS 和 DASH 共用同一套 fMP4 分片，只需维护两份 manifest，存储成本减半。

追问：直播场景下 HLS 延迟为什么高？如何优化？
HLS 延迟 = 分片时长 x 3（编码缓冲 + 播放列表刷新 + 缓冲区预载）。优化方向：缩短分片到 2-4 秒、用 LL-HLS 的部分分片预加载、或改用 WebRTC/FLV 方案。

四、CDN 缓存策略

• 分片缓存：每个 .ts/.m4s 独立缓存，命中率高，TTL 可设较长（1-24h）
• 播放列表缓存：.m3u8/.mpd 动态更新，TTL 短（直播 5s，点播 5min）
• 缓存锁：proxy_cache_lock 防止同一分片并发回源击穿缓存
• 智能预加载：播放器预取后续 2-3 个分片和下一码率档位

五、传输层优化

HTTP/2 多路复用减少连接数、头部压缩降低开销；HTTP/3（QUIC）基于 UDP 减少握手延迟、改善弱网拥塞控制。点播用 HTTP 足够，直播低延迟场景倾向 UDP（WebRTC）。

六、播放体验优化

首屏慢的典型链路：DNS 解析 → TCP 连接 → TLS 握手 → 请求 m3u8 → 请求分片 → 解码首帧。优化手段：预连接、初始选低码率快速起播、增加关键帧频率（GOP 缩小到 1-2 秒）、预加载首屏分片。

拖动进度条时，需要定位到目标时间对应的关键帧所在的分片。关键帧间隔越短，seek 响应越快，但编码效率略降。

七、质量监控

关键指标：首屏时间、卡顿率、码率切换频率、平均播放码率。播放端通过 waiting/playing 事件采集缓冲数据，定时上报，服务端做聚合告警。

追问：卡顿率高但码率切换少，可能是什么原因？
ABR 没有及时降码率，可能是吞吐量估算偏高、缓冲区水位阈值设置过高，或者分片缓存未命中导致回源延迟。