| 级别 | 方案 | 延迟 | 相对成本 |
|---|---|---|---|
| 一级 | HLS 切片调优（6s 切 3s） | 4-6 秒 | 1 倍 |
| 二级 | LL-HLS | 2-4 秒 | 1.3 倍 |
| 三级 | HTTP-FLV | 2-4 秒 | 1.2 倍 |
| 四级 | WebRTC | 0.2-0.5 秒 | 2.5-3 倍 |
默认 HLS 的 6 秒切片加 3 片缓冲，端到端 15 秒很正常。把切片改 2 秒、缓冲改 2 片，延迟能压到 6 秒左右，代价是请求频率翻三倍、CDN 请求数费用上涨。这一步零架构改动，多数「延迟有点高」的团队做到这一级就够了。
LL-HLS 通过部分切片加载把延迟再压 2 秒，但苹果生态外要自己处理播放器兼容。HTTP-FLV 更直接：长连接拉流，延迟 2-4 秒，浏览器端用 flv.js 播放，是当前网页直播的主力方案。两者都不需要动推流端，服务端改造范围可控。推流端的协议选择与延迟的关系，见推流与多端分发方案的协议对比。
要连麦、要几百毫秒延迟，只有 WebRTC。代价清单：UDP 端口防火墙穿透、SFU 服务部署、播放器换成标准 WebRTC 栈、弱网丢包重传逻辑。一个经验数字：WebRTC 方案的运维复杂度约是 HTTP-FLV 的 3 倍，团队没有专职流媒体工程师时慎上。连麦场景的完整设计在互动直播功能设计里。
低延迟方案在弱网下的表现才是硬指标。WebRTC 在 5% 丢包下仍能维持 0.5 秒量级延迟，靠 FEC 前向纠错加 NACK 重传的双保险；HTTP-FLV 在同样丢包率下会直接卡顿——TCP 重传的队头阻塞没有解。测试方法固定：用流量控制工具把下行限到 1 Mbps、丢包 3%，观察卡顿率和延迟漂移。没做过弱网测试就上线的低延迟方案，等于让第一批真实用户替你做测试。
分级分场景：普通场次走 HTTP-FLV，重点场次和连麦走 WebRTC，一套系统两套播放策略，成本和体验都顾住。别为了指标好看全站上 WebRTC——延迟数字好看，账单和故障都不好看。服务器侧的承接能力，回到流媒体服务器选型对照。