选直播协议，先问观众要不要实时回应，而不是只比较协议名称。直播流分发中的低延迟协议选择，取决于从采集、编码、传输到播放的整条链路；协议只是其中一环。单向观看通常重视兼容性和规模，连麦、远程问答则更在意说话后对方多久能听见。
先分清三种协议各自负责什么
RTMP：常见于推流接入
RTMP基于持续连接传输，长期用于编码器或推流软件把音视频送到直播服务端。它的接入方式成熟，但不能因此认为观众端也应直接使用RTMP：现代浏览器通常不原生播放RTMP，往往需要服务端转封装或转码。直播流分发中的低延迟协议选择若只关注“推流快不快”，就容易漏掉播放端的实际等待时间。
HLS：播放兼容和分发能力较强
HLS把媒体切成分段，通过HTTP交付，适合多终端观看，也便于借助CDN分发。常规HLS会等待分段生成和播放器缓冲，端到端延迟可能达到数秒至几十秒，具体受分段时长、播放列表更新和缓冲策略影响。低延迟HLS可缩短等待，但需要播放端、服务端和分发链路共同支持，不能只改一个参数就保证效果。
WebRTC：优先满足实时互动
WebRTC面向实时音视频通信，适合连麦、远程协作、在线答疑等需要快速对话的场景。在网络条件较好、链路配置合理时，端到端延迟常以亚秒级为目标；遇到跨网、弱网或复杂中继路径，时延和稳定性都会变化。它的互动体验好，但会增加连接管理、网络穿透和大规模分发的工程复杂度。
低延迟究竟该看哪些指标
直播流分发中的低延迟协议选择，应把“低”落实到可测指标，而不只看协议说明中的理论能力。
- 端到端延迟：从现场画面发生到观众屏幕显示的时间。用同步时钟或带时间标记的画面，在实际采集、编码、服务端和播放链路中测量。
- 首屏时间：观众打开页面后多久看到画面。首屏快不代表持续播放延迟也低，两项应分别记录。
- 卡顿率与弱网恢复：检查丢包、带宽波动时是否频繁停顿，以及恢复需要多久。互动直播还应观察声音和画面是否同步。
测试时至少覆盖有线网络、常见家庭Wi-Fi和移动网络，并在不同终端重复播放。记录中注明清晰度、编码参数、播放器缓冲设置和网络条件；否则不同方案的数据无法公平比较。
按场景选型：先定目标，再搭链路
- 以单向观看为主、观众规模较大：优先评估HLS及其分发兼容性。能接受数秒以上延迟时，常规HLS实现简单；需要更快反馈时，再评估低延迟HLS，并验证终端支持和卡顿表现。
- 必须边看边说、快速轮流发言：优先测试WebRTC。先确认互动人数、网络环境和服务端承载方式，再测真实端到端延迟；不要仅凭“实时”字样作决定。
- 需要兼顾推流设备和多种播放端：可采用RTMP接入、服务端处理后分别输出HLS或WebRTC的架构。不同观众走不同播放链路，代价是要维护多套转封装、播放和监控配置。
一场以主讲人为主、问答较少的公开直播，可能更适合HLS；需要观众即时插话的远程讨论，则应优先验证WebRTC。直播流分发中的低延迟协议选择没有脱离场景的固定答案，合理做法是先写下可接受的延迟、目标终端和并发需求，再用同一段内容做对照测试。
常见问题
RTMP是不是一定比HLS延迟低？
不能这样比较。RTMP常用于推流接入，HLS常用于播放分发；实际延迟还取决于服务端处理、转封装和播放器缓冲。
WebRTC能保证任何网络下都低于一秒吗？
不能。亚秒级是适合条件下的目标，不是对所有网络和设备的保证。应在目标用户的网络环境中实测。
只把HLS分段调短就能降低延迟吗？
不一定。分段变短可能增加请求频率，也可能影响稳定性；还要检查服务端更新、分发链路和播放器缓冲是否配合。
选型时最先做什么？
明确是否需要实时互动，并设定端到端延迟目标；随后对照实际终端和网络测试。这样才能把直播流分发中的低延迟协议选择落到可验证的结果上。
