直播延迟从哪里来？RTMP、HLS、LL-HLS、WebRTC 低延迟方案全解析

做企业直播时，“为什么我这边说完话，观众要过好几秒才听到”是最常见的问题之一。要解决延迟，首先要知道延迟是从哪里来的。

优化延迟时，先从“分片等待 + 播放缓冲”入手，而不是一味升级带宽。

一、直播链路上的六段延迟

一条典型的直播链路可以拆成六个环节，每个环节都会贡献一部分延迟：

1. 采集与前处理：摄像头、采集卡、美颜或画面合成，通常是几十到上百毫秒。
2. 编码：编码器需要缓存若干帧做运动估计。开启 B 帧、使用较慢的编码预设会增加延迟。
3. 推流（第一公里）：主播端到接入节点的网络传输，受上行带宽和网络抖动影响。
4. 转码与封装：服务端转出多种清晰度，再封装成 HLS、FLV 等格式。转码层级越多，延迟越大。
5. CDN 分发：边缘节点回源、逐级缓存，一般不是主要瓶颈，但回源慢时会放大首屏时间。
6. 播放缓冲：播放器为了抗抖动会预先缓存一段内容，这往往是延迟的“大头”。

经验上，切片协议的分片等待 + 播放器缓冲是延迟最主要的来源。优化时应先从这里入手，而不是一味升级带宽。

二、主流协议的延迟与适用场景

协议	典型延迟（量级）	优势	局限	适用场景
RTMP / HTTP-FLV	数秒	推流生态成熟，延迟较低	浏览器原生不支持 FLV，需借助 JS 播放器；iOS 浏览器兼容性差	推流上行、PC 端播放
HLS	十秒级及以上	兼容性最好，CDN 友好，易扩展	需等待分片生成，延迟高	大规模单向观看、回放
LL-HLS	数秒	保留 HLS 兼容性与 CDN 扩展性	需要服务端、CDN、播放器全链路支持	互动要求中等的大型直播
WebRTC	亚秒级	实时性最好，浏览器原生支持	大规模分发成本高，需 SFU 与边缘部署	连麦、互动课堂、竞拍
SRT	可配置，通常数百毫秒到数秒	抗丢包能力强，适合公网远距离传输	主要用于贡献链路，不直接面向观众	外场信号回传、跨地区推流

上表的数值是常见量级，实际表现取决于参数配置和网络状况，并非任何厂商的承诺值。

HLS 为什么慢

HLS 把直播流切成一个个 TS 或 fMP4 分片，播放器下载播放列表（m3u8）后才开始拉取分片。按照 RFC 8216 的建议，客户端一般不会从最后一个分片开始播放，而是从倒数第三个分片附近开始。若分片时长 6 秒，仅这一项就可能带来十几秒的延迟。

LL-HLS 怎样提速

Apple 提出的低延迟 HLS 引入了“部分分片（Partial Segment）”、阻塞式播放列表刷新和预加载提示等机制，播放器不必等待完整分片生成，就能拉取更小的数据块，从而把延迟压到数秒。它的前提是源站、CDN 和播放器都要支持这些扩展。

WebRTC 的取舍

WebRTC 基于 UDP 传输，并内置拥塞控制和抗丢包机制，能做到亚秒级互动。随着 WHIP（WebRTC-HTTP 推流协议）标准化，推流侧的接入也更简单了。但每个观众都需要与服务器保持实时连接，大规模分发要靠 SFU 级联，成本明显高于 CDN 分发。

三、降低延迟的实操清单

• 对齐 GOP 与分片：GOP 设为 1～2 秒，分片时长为 GOP 的整数倍，避免分片里关键帧错位导致首屏变慢。
• 减少 B 帧或关闭 B 帧：对互动要求高的场景，编码器可以使用 zerolatency 一类的低延迟调优参数。
• 缩短分片时长：HLS 分片可以从 6 秒降到 2 秒左右，但请求数会增多，需要评估 CDN 成本。
• 调小播放器缓冲：在弱网用户比例不高时，可以适当降低起播缓冲和最大缓冲，并配合追帧策略（缓冲过大时加速播放）。
• 按场景混合架构：主讲人与连麦嘉宾走 WebRTC，普通观众走 CDN 低延迟协议，兼顾体验与成本。
• 监控端到端延迟：在画面中叠加时间戳，或通过 SEI 携带推流时间，在播放端计算真实延迟，用数据驱动优化。

四、如何选择

如果你的直播以单向观看为主（发布会、讲座、年会），把延迟控制在数秒以内通常就足够了，优先保证稳定性与覆盖面；如果是在线课堂连麦、互动答题、直播竞拍，就需要 WebRTC 级别的实时性。

对于不想自建全链路的团队，也可以直接使用成熟的企业直播平台。不少平台提供低延迟直播与多人连麦能力，建议挑选几家，在自己的网络环境里实测延迟后再决定架构。