流媒体传输协议全景：14 种技术的原理、局限与选型根因

这 14 个流媒体技术不在同一层。一条完整直播链路通常是：

摄像头/编码器 → 摄取（RTMP / SRT / RIST / WebRTC-WHIP / WebTransport）→ 转码 → 交付（HLS / LL-HLS / DASH / LL-DASH / HESP / HTTP-FLV）→ 观众

选型要先看自己卡在链路的哪一段，而不是问「谁更好」。

flowchart TD
    A["摄像头/编码器"] --> B["摄取层<br/>RTMP · SRT · RIST<br/>WebRTC · WebTransport"]
    B --> C["转码/封装<br/>CMAF · ABR · 多码率"]
    C --> D["交付层<br/>HLS · LL-HLS · DASH<br/>HTTP-FLV · WebRTC · HESP"]
    D --> E["观众端"]
    style A fill:#2196F3,color:#fff
    style B fill:#FF9800,color:#fff
    style C fill:#9C27B0,color:#fff
    style D fill:#4CAF50,color:#fff
    style E fill:#2196F3,color:#fff

上图是一条标准直播链路的五段式结构。摄取层负责把信号从摄像头搬到平台，交付层负责把处理后的流分发给观众。RTSP（摄像头控制）和 NDI（局域网制作）不在主链路上，各自独立工作。

核心矛盾：延迟↓ 与 规模↑ / 兼容↑ 互斥，只能按场景权衡。

先给结论：怎么选

对比矩阵

交付 / 播放 / 实时互动层（9 种）

延迟指典型「端到端（glass-to-glass）」直播延迟。WebCodecs 是客户端编解码积木，自身几乎不加延迟，延迟取决于搭配的传输层。

下表列数较多，移动端可横向滚动查看。

摄取 / 贡献 / 专业网络层（5 种）

这一层解决「信号怎么从摄像头/编码器到平台和转码器」，通常不面向最终观众直接播放。

端到端延迟量级

面向观众的交付 / 播放延迟

摄取 / 贡献 / 局域网延迟（第一跳）

NDI / RTSP 仅限局域网，不能作为公网交付；RTMP 的「延迟」是摄取延迟，到观众还需经 HLS/DASH 二次封装。

逐技术深挖

WebCodecs

• 是什么：W3C 标准 API，把浏览器内置的音视频编解码器（VideoEncoder / VideoDecoder / AudioEncoder / AudioDecoder / ImageDecoder）直接暴露给 JS。它不做解封装/封装，需要配合 mp4box.js、webm-muxer 处理容器。让网页能逐帧（VideoFrame / EncodedVideoChunk）处理媒体，而不是把 MediaStream 当黑盒。
• 核心机制：异步、离主线程，可放进 Web Worker；通过 Insertable Streams（MediaStreamTrackProcessor / MediaStreamTrackGenerator）与媒体轨道对接；可与 WebTransport、WebRTC 自由组合。
• 优势：直接调用系统硬件编解码，720p 解码约为 FFmpeg.wasm 的 10–20×（具体倍数随负载和编解码器变化），内存占用也更低；逐帧控制，适合视频编辑、逐帧处理、机器学习推理、滤镜、截帧；2026 年已成 Baseline（Chrome/Edge 94+、FF 130+、Safari 16.4+）。
• 局限：不是传输协议，必须自己搭传输/封装层；编解码覆盖取决于操作系统；编码参数远少于 FFmpeg；Insertable Streams 碎片化（Firefox 缺 MediaStreamTrackProcessor，Safari 18+ 才补上）。
• 根因：设计上只做编解码这一层，把传输/封装/信令留给开发者，带来灵活也意味着无法开箱即用地直播。兼容性碎片化源于规范按接口而非按浏览器演进。
• 适合：浏览器内视频编辑、实时滤镜、逐帧处理、机器学习推理、自定义流管线。
• 不适合：想直接拉一路流播放的简单需求（请用 HLS/FLV）。

WebRTC

• 是什么：浏览器原生实时音视频通信标准，基于 SRTP/DTLS，走 UDP，自带拥塞控制。三种拓扑：Mesh（P2P）、SFU（选择性转发）、MCU（服务端混流）。WHIP（RFC 9725）是浏览器贡献信令的成熟路径。
• 核心机制：端到端直连（或经 SFU 转发），双向、有状态；用 Simulcast/SVC 做多档码率。
• 优势：原生支持、零插件、端到端 <300ms；强制加密；双向 + DataChannel；SFU 是 5–100+ 人最佳平衡点。
• 局限：无法被 CDN 缓存，扩展靠堆服务器；信令 O(N²)，Mesh 超 4 人崩溃；约 40–60% 企业网被迫走 TURN 中继（万级流月带宽账单可达数万美元）；SFU 触达物理 CPU 上限。
• 根因：为点对点实时而生，不是为「一对百万广播」设计。延迟优势来自「不经缓冲、不可缓存、逐连接独立」，同一特性在大规模分发时变死穴——没有边缘缓存，压力全回源站/SFU。
• 适合：视频会议、连麦、云游戏、在线教育。
• 不适合：万级观众单向直播（配合 HLS/FLV 做双路）。

WebTransport

• 是什么：W3C API，基于 HTTP/3（QUIC/UDP）的现代传输层。提供「可靠流」与「不可靠数据报」两种通道，多路复用、无队头阻塞。是传输不是媒体——视频得自己接 WebCodecs 或 MoQ（Media over QUIC）。
• 核心机制：QUIC 连接迁移（Wi-Fi→蜂窝不断）、0-RTT 建连；WHIP-over-WebTransport 是浏览器贡献信令路径；MoQ 在其上做 CDN 式 fan-out（仍草案）。2026 年 3 月 Safari 26.4 起全平台 Baseline。
• 优势：亚秒、低开销，连接迁移不断流；无队头阻塞；比 WebRTC 简单（无 ICE/STUN/TURN）；全平台 Baseline。
• 局限：不自带媒体栈，必须配 WebCodecs / MoQ；UDP/443 被过滤时直接失败（无 TCP 回落）；纯 client→server，无 NAT 穿透；MoQ 仍草案，大规模 fan-out 未成熟。
• 根因：只搬字节，视频编解码得自己接。QUIC 带来低延迟与迁移，但 UDP-only 意味企业网过滤是硬天花板（WebRTC 至少还能 TURN-over-TCP 回落）。做大规模分发必须等 MoQ 成熟。
• 适合：浏览器-first 自定义摄取、自管服务器、亚秒贡献目标。
• 不适合：需要 CDN 大规模 fan-out、严格过滤 UDP 的网络。

HTTP-FLV

• 是什么：FLV 容器通过 HTTP 分块传输，浏览器用 flv.js（基于 MSE）实时解封装成 fMP4。RTMP 的低延迟替代 + 免 Flash。
• 核心机制：服务端长连接流式下发 FLV Tag；延迟来自 GOP 长度、服务端 I 帧缓存与两端 buffer。
• 优势：延迟低（1–3s，优化后 ~1s），首屏快；实现简单；PC/Android 支持好；国内生态成熟。
• 局限：iOS Safari 完全不支持（无 MSE），必须回退 HLS；固定码率，无原生 ABR；无持久化缓存；必须 H.264 + AAC/MP3。
• 根因：iOS 死穴来自 Apple 从未在移动 Safari 实现 MSE，而 flv.js 全部建立在 MSE 上——是平台策略而非技术缺陷。固定码率因 FLV 单流封装、没有多码率索引。本质是「用长连接绕过切片」换低延迟，也失去 HLS 的缓存与自适应。
• 适合：PC/Android 低延迟直播、安防监控、电商互动。
• 不适合：iOS H5、需全平台一致、需 ABR 的大规模场景。

MJPEG

• 是什么：视频当作一串独立 JPEG，通过 HTTP multipart/x-mixed-replace 一帧帧推。每帧完整图片，无任何帧间压缩。
• 核心机制：逐帧独立编码/解码，浏览器原生支持该 MIME，无需解码库。
• 优势：极致简单，几乎任何设备直接看；逐帧独立，错误恢复易；解码 CPU 极低；帧级延迟极低。
• 局限：带宽爆炸，同画质约 H.264 的 10 倍；几乎无音频；存储成本极高；消费级基本被取代。
• 根因：只用帧内压缩，放弃帧间时间冗余，换简单性与低延迟也造成 10× 带宽惩罚。只在「兼容性 > 效率」「帧独立 > 成本」的窄场景存活（legacy 摄像头、医疗影像、嵌入式监控）。
• 适合：IP 摄像头/老监控、医疗/科研成像、帧级精确访问的嵌入式设备。
• 不适合：高分辨率、高帧率、带宽敏感或需长期存储的现代应用。

HLS

• 是什么：Apple 2009 年 HTTP Live Streaming。服务端切 .ts（或 fMP4/CMAF）片段，配 .m3u8 索引；Safari 原生，其余靠 hls.js。
• 核心机制：分段 + 索引 + 播放器缓冲。延迟 = 编码 → 等整段完成 → CDN → 播放器缓冲的累加。
• 优势：全平台兼容；原生 ABR；契合 CDN，可百万级并发；DRM/时移/录制生态完善。
• 局限：高延迟（15–30s）；不适合实时互动；单向广播；部署较复杂。
• 根因：把可靠性和可扩展性放在延迟之前，必须等整段（6–10s）编码完成 + 多段预缓冲，吃掉 20s+。分段设计让它能被 CDN 缓存、做 ABR，能廉价扩展百万观众——代价是延迟。为电视级可靠分发而生，非实时互动。
• 适合：点播、大规模直播、对延迟不敏感的赛事分发、需 ABR 的全平台场景。
• 不适合：连麦、互动、任何 <5s 延迟场景。

LL-HLS

• 是什么：Apple 2020 年 HLS 低延迟扩展，保留全部优势同时将延迟压到 2–5s。向后兼容。
• 核心机制（核心支柱）：① Partial Segments（EXT-X-PART，把段切 200–400ms CMAF chunk，边产边发）；② Blocking Playlist Reload（播放器用 _HLS_msn 预占下个播放列表版本）；③ Preload Hints（EXT-X-PRELOAD-HINT，提前告知下一片 URL）；④ Playlist Delta Updates（CAN-SKIP-UNTIL，增量更新）与 Rendition Reports（EXT-X-RENDITION-REPORT，跨变体报告）。前三者直接压延迟，后两者优化 ABR 切换与多码率协调。
• 优势：延迟 2–5s 仍走标准 HTTP/CDN；保留 ABR、缓存、DRM；向后兼容；2026 年 hls.js 1.1+、Shaka 4.0+、iOS 14+ 原生支持。
• 局限：全链路须支持（packager、源站、每个 CDN POP、播放器）；CDN 把 partial 当独立缓存项则增益尽失；仍难稳定 <1s；单向广播。
• 根因：没颠覆 HLS 的 HTTP 模型，只是把「等整段」拆成「边产边发」，保住 CDN 红利也继承 HTTP 分发下限——每个 chunk 仍走一次请求与边缘节点，物理上难进亚秒。真正坑在运维：partial + chunked + 请求合并必须贯穿整条链路，任一节点不当配置就回退经典 HLS。
• 适合：大规模低延迟直播、已用 HLS 想降延迟而不推翻架构。
• 不适合：亚秒级互动、CDN 不支持 partial segment 的保守环境。

MPEG-DASH / LL-DASH

• 是什么：ISO/IEC 23009-1 国际标准（MPEG 联盟），与 HLS 原理相同但开放。用 .mpd（XML）+ .m4s（fragmented MP4），codec 无关。LL-DASH 借助 CMAF chunked 把延迟压到 2–3s，配 QUIC 可进 sub-2s。
• 核心机制：分段 + MPD + 客户端 ABR（dash.js / Shaka）。与 HLS 共用 CMAF 后可「一次封装、双协议分发」。
• 优势：开放标准无锁定；codec 自由；原生 ABR，CDN 友好；与 HLS 共用 CMAF 提升存储/缓存效率。
• 局限：iOS/Safari 不原生支持（需 dash.js/Shaka）；默认分段 2–4s 仍偏长；MPD/多 DRM 配置稍复杂；加密模式（CENC）与 HLS（CBCS）不同，常致「打包一次」回退「打包两次」。
• 根因：灵活是双刃剑——开放换来生态碎片化，Apple 选择不原生支持以推自家 HLS。CMAF 让两者共享碎片，「二选一」变「两者都要」；但加密模式差异仍是真实摩擦点。适合非 Apple 优先、需 codec 自由、多 DRM 的场景。
• 适合：非 Apple 优先、多 DRM、需 codec 自由、Android/Chrome 大规模交付。
• 不适合：纯 iOS 原生播放（除非走 dash.js）。

HESP

• 是什么：THEO（现 Dolby OptiView）提出的 HTTP 自适应流，IETF 草案（draft-theo-hesp），HESP Alliance 推动。用两条流实现亚秒：Init 流（每包独立样本，任意包可起播）+ Continuation 流（HTTP Range 拉后续）。
• 核心机制：Init 流让解码器随时从任意包初始化，绕开 GOP 边界限制；因此能用大 GOP（10–12s）保持压缩效率又不影响起播/切换。ABR 可在任意时刻切换，zapping <100ms。只需 CDN 支持 HTTP CTE + Range。
• 优势：亚秒延迟（~0.5–1s）+ 快 zapping（<100ms）；大 GOP 比 LL-HLS 省带宽约 20%；ABR 随时切换弱网不卡；CDN 兼容。
• 局限：生态较新，需专用 player；需专用 packager + 双流存储；标准仍草案；部署面比 LL-HLS 窄。
• 根因：用 Init 流绕开 GOP 边界限制，大 GOP（压缩高效）与低延迟/即时 ABR 可兼得，而 LL-HLS 被迫小 GOP 换低延迟（牺牲压缩率）。代价是双流与专用组件，生态未铺开。
• 适合：亚秒级大规模交付、互动直播、需快 zapping 的 OTT。
• 不适合：不想引入专用 packager/player 的保守环境。

RTMP

• 是什么：Adobe（原 Macromedia）2002 年 TCP 协议，端口 1935。Flash 时代产物，如今只活作摄取标准：编码器推给平台，平台再转封装成 HLS/DASH/WebRTC。RTMPS=TLS，RTMPT=HTTP 隧道。
• 核心机制：长连接 TCP，AMF 握手，chunk 流；简单 URL + stream key 推流。Enhanced RTMP（v2）开始支持 HEVC/AV1/VP9/HDR。
• 优势：编码器普遍支持（OBS/vMix/硬件/手机）；平台普遍接受（Twitch/YouTube/FB/TikTok）；防火墙友好可回落 80/443；搭建极简。
• 局限：浏览器无法直接播放（Flash 死）；TCP 重传在丢包时抬升延迟；无原生加密（需 RTMPS）；单视频单音频，无 Simulcast；编解码偏老。
• 根因：活下来只因「摄取端生态粘性」——全行业编码器默认输出 RTMP，替换需协调千万设备；播放端已迁到 HLS/DASH/WebRTC。本质是摄取标准不是交付标准。TCP 本性在公网丢包时靠重传保可靠，也付出延迟代价。「过时但不可替代」是摄取与播放两端演进速度不同步的结果。
• 适合：直播摄取第一跳、legacy 编码器、防火墙严格环境。
• 不适合：浏览器播放、亚秒互动（用 SRT/WHIP 替代）。

SRT

• 是什么：Haivision 开源 UDP 可靠传输，ARQ + 前向缓冲做丢包恢复，AES-128/192/256 原生加密，codec 无关。专为不可预测公网做低延迟可靠传输。
• 核心机制：UDP 打底 + ARQ 选择性重传 + 可调缓冲；可被 CDN/OTT 消费。
• 优势：公网丢包下仍稳，亚秒延迟；原生 AES 加密；codec 无关；CDN/OTT 友好，采用率上升。
• 局限：生态比 RTMP 新，部分旧设备不支持；配置比 RTMP 复杂（缓冲/延迟调参）；UDP/443 可能被过滤；非播放协议，需转封装。
• 根因：在 UDP 上自建可靠（ARQ）而非靠 TCP，既快又抗丢包，是取代 RTMP 做远距离贡献的核心。代价是需自建/配置且依赖 UDP 可达。解决公网远距离可靠贡献，非端到端播放，仍要和后段交付配合。
• 适合：广电级远距离、海外直播、弱网/移动回传贡献。
• 不适合：浏览器直接播放、纯 legacy 环境。

RIST

• 是什么：VideoLAN 主导的开放标准（VSF TR-06 系列技术建议），UDP 可靠传输。强调跨厂商互通、强拥塞控制（BCA）与多路径，定位企业/广电级贡献。
• 核心机制：DTLS + AES；ARQ + 选择性重传；多路径智能调度；可承载音视频/字幕/时间码。
• 优势：开放免费，跨厂商互通；强拥塞控制，多路径；企业专网/多地点回传友好；原生 DTLS+AES。
• 局限：生态更稚嫩，工具/文档少于 RTMP；技术门槛高（重传/多路径/序列化）；中小团队上手成本大；非播放协议。
• 根因：与 SRT 同解决公网可靠 UDP，但更强调开放标准 + 多路径 + 强拥塞控制，定位企业/广电互通。代价是生态年轻、学习曲线陡——复杂设计正为高可靠，也抬高落地门槛。适合多厂商、企业专网、不能绑死单厂商的诉求。
• 适合：多厂商互通、企业专网、多路径远距离贡献。
• 不适合：中小团队快速上手、legacy 设备。

RTSP

• 是什么：RFC 2326 应用层「网络遥控」协议（RTSP 1.0；2.0 为 RFC 7826，尚未广泛部署）。不发媒体本身，只发控制指令（OPTIONS/DESCRIBE/SETUP/PLAY/PAUSE/TEARDOWN），真媒体走 RTP。常配 ONVIF 做设备发现与 PTZ 控制。
• 核心机制：命令与媒体分离；典型跑局域网 UDP，亚秒延迟。IP 摄像头普遍支持，浏览器不原生支持。
• 优势：亚秒延迟，实时 PTZ 控制；IP 摄像头/NVR 广泛支持；codec 自由（H.264/H.265）；控制精准。
• 局限：浏览器不原生支持，需专用播放器；默认不加密；防火墙可能拦端口；公网不稳定，无设备发现（靠 ONVIF）。
• 根因：是媒体遥控协议而非传输协议——只发指令，真媒体走 RTP；设计于封闭局域网，公网/加密不是目标。浏览器不直接支持因它从未为 Web 播放设计。需上公网/上云必须经媒体服务器转成 RTMP/HLS。
• 适合：安防监控、PTZ 控制、局域网实时查看。
• 不适合：公网直播、浏览器直接播放。

NDI

• 是什么：NewTek（现 Vizrt）视频-over-IP 协议，把演播室信号跑在标准以太网。mDNS 自动发现即插即用。全质量约 130–150 Mbps/1080p60，压缩版 NDI|HX 约 10–20 Mbps（H.264/H.265）。
• 核心机制：标准以太网 + 自动发现；用现成网络替代 SDI/HDMI 布线。600+ 厂商、2000+ 产品支持。
• 优势：亚帧延迟（~16ms）；即插即用零配置；用现成网络替代专用视频矩阵省布线；跨品牌互通。
• 局限：仅局域网，非公网交付；高带宽（全质量需千兆/万兆）；依赖 managed 交换机 + QoS；专有生态（虽开放 SDK）。
• 根因：为演播室内部 IP 化而生，牺牲公网可达换极致低延迟与零配置；高带宽在局域网不是问题，到公网不可行。和 SDI/HDMI 互补而非替代——摄像头走 SDI 进编码器，编码器出 NDI 内部路由，最终仍经 RTMP/SRT 上云。是制作域协议，不是分发域协议。
• 适合：现场制作、演播室路由、控制台视频墙、教育/企业 PTZ。
• 不适合：公网分发、跨 Internet 传输。

根因总览：为什么「低延迟」和「大规模」天生互斥

1. 延迟来自四段累加：编码 + 封装/分段 + CDN 传播 + 播放器缓冲。想低延迟每段都要砍（小 GOP、小分段、小 buffer），但 buffer 越小越怕抖动，可靠性下降。
2. 可缓存 ⇄ 实时互斥：HLS/FLV/DASH/LL-HLS 走 HTTP 能被 CDN 边缘缓存，廉价扩展百万观众；WebRTC/WebTransport 每条流唯一且双向/直连，不可缓存，扩展只能堆服务器。
3. 压缩效率 ⇄ 简单性互斥：MJPEG 放弃帧间压缩换极简低延迟；H.264/HEVC 用时间冗余换带宽。没有又快又省又简单的免费午餐。
4. 平台策略决定兼容：iOS 无 MSE → flv.js 失效；Safari 晚支持 WebCodecs/WebTransport；Apple 推原生 HLS。很多「技术局限」是厂商路线选择。
5. 抽象层错位：WebCodecs 是编解码积木，RTMP/SRT 是摄取，NDI 是局域网制作，HLS/DASH 是交付。拿不同层技术比延迟本身是伪问题——必须先定位链路位置。
6. 全链路木桶：LL-HLS/HESP 增益取决于最弱一环（packager→源站→每个 CDN POP→播放器）。任一节点不支持 partial/双流，延迟回退经典 HLS。
7. 可靠性来自冗余：SRT/RIST 在 UDP 上自建 ARQ 换可靠，TCP（RTMP）靠重传换可靠——都付出延迟。公网不可预测，可靠与低延迟必须取舍。
8. GOP 边界约束：播放器需关键帧才能起播，LL-HLS 被迫小 GOP 换低延迟（牺牲压缩），HESP 用 Init 流绕开 → 大 GOP 也能亚秒。这是同层协议间的根本差异。

选型指南

flowchart TD
    A["需要双向<br/>实时互动?"] -->|"是"| B["WebRTC (SFU)"]
    A -->|"否"| C["观众量级?"]
    C -->|"万级以下<br/>PC/Android"| D["HTTP-FLV<br/>1-3s"]
    C -->|"百万级全平台"| E["延迟底线?"]
    E -->|"≥10s"| F["HLS / DASH"]
    E -->|"2-5s"| G["LL-HLS / LL-DASH"]
    E -->|"<1s"| H["HESP"]
    style B fill:#4CAF50,color:#fff
    style D fill:#2196F3,color:#fff
    style F fill:#FF9800,color:#fff
    style G fill:#2196F3,color:#fff
    style H fill:#9C27B0,color:#fff

上图覆盖了交付层的主流场景。摄取层的选择更简单：

• 主播推流第一跳：通用/legacy → RTMP；弱网/远距离/海外 → SRT；企业多厂商/多路径 → RIST；浏览器贡献 → WebRTC-WHIP 或 WebTransport。
• 安防摄像头 / 演播室：摄像头控制 → RTSP（配 ONVIF）；legacy 帧级 → MJPEG；局域网制作路由 → NDI。
• 浏览器内逐帧处理：WebCodecs 做编解码，自己接封装与传输。
• 能接受双路架构：生产级大型直播常做 WebRTC（互动连麦）+ HLS/FLV（大规模分发）双路，各取所长。

参考来源

• Chrome for Developers — Video processing with WebCodecs
• MDN / Can I Use — WebCodecs 与 WebTransport 浏览器支持（2026 Baseline）
• W3C — WebTransport；IETF — QUIC (RFC 9000)、HTTP/3 (RFC 9114)
• IETF — WHIP (RFC 9725)
• Ant Media — WebRTC Topology (Mesh/SFU/MCU)、WebRTC Scalability 2025
• Apple Developer — Enabling Low-Latency HLS
• Bitmovin — Fundamentals of LL-DASH and LL-HLS
• Streaming Media — LL-HLS and LL-DASH sub-3-second latency
• IETF — HESP draft (draft-theo-hesp)；Dolby OptiView — What is HESP
• VSF — RIST TR-06 系列技术建议 (TR-06-1/2/3)
• IETF — RTSP (RFC 2326 / RFC 7826)
• Dacast — RTMP in 2026（摄取标准）、SRT 对比
• LiveAPI — RTSP vs RTMP；ONVIF — RTSP 与设备发现
• Epiphan — NDI Streaming 2025
• ForaSoft — RTMP glossary、WebTransport/WHIP 词条