| 协议 | 典型延迟 | 用在哪 | 短板 |
|---|---|---|---|
| RTMP | 1-3 秒 | 推流接入的事实标准 | TCP 在弱网下抖动大 |
| SRT | 0.5-1 秒 | 跨公网弱网推流 | 播放端生态弱，需转 RTMP |
| HTTP-FLV | 2-4 秒 | 网页播放主力 | 依赖 HTTP/1.1 长连接 |
| HLS | 6-15 秒 | 多端兜底、小程序 | 延迟高 |
| WebRTC | 0.2-0.5 秒 | 低延迟与连麦 | 部署与运维复杂 |
常见的组合是：主播用 RTMP 或 SRT 推流，服务端转码后，网页走 HTTP-FLV，移动端和小程序走 HLS，需要互动的场次切 WebRTC。单协议通吃的方案目前不存在，协议桥接能力是直播推流方案的核心指标。
转码的目的不是画质，是覆盖。观众的网络从 4G 到千兆宽带都有，一路原画推流必须转出 2-3 个档位：1080p 原画、720p 主力、480p 兜底。软编兼容性好但一路 1080p 要吃掉一台 8 核机器的六成 CPU；硬编快 5 倍但机型适配要花两周踩坑。档位怎么排、成本怎么算，落点在流媒体服务器选型的硬件编码章节。
源站的带宽撑不住并发，这是常识。直播的CDN分发结构是三级：源站（推流接入与转码）→ 中心节点（切片与缓存）→ 边缘节点（观众就近接入）。观众分散在多区域时，边缘节点的覆盖质量直接决定卡顿率，选 CDN 时别只看带宽单价，要看目标区域的节点密度和回源延迟。拉流端若走 WebRTC，分发结构要单独设计，这部分在低延迟实现路径里展开。
首屏时间（点开到出画面）超过 3 秒，流失率接近翻倍。三个抓手：播放端预加载首帧；HTTP-FLV 从 GOP 关键帧处开始下发，不然要等下一个关键帧，平均多等 2 秒；App 端做播放器常驻，避免每次冷启动。多端适配的真实差异比想象大：小程序不支持 HTTP-FLV 只能走 HLS；iOS Safari 上 flv.js 的兼容要真机逐版测；Android 低端机解码能力有限，480p 档位建议做成这类机型的默认档。验收时用 20 台真机过一遍机型清单，模拟器测不出解码问题。
单路推流跑通 RTMP 接入加网页播放，两周足够；加上转码档位和 HLS 多端，四周到六周；再叠 CDN 分发和多区域边缘节点，两个月左右。跳过压测直接上线的项目，第一次活动直播就是事故现场。压测方法见方案总览引用的服务器选型压测章节。