一、为什么要关注流媒体协议？
因为协议决定了：你的视频能不能播、卡不卡、延迟多少、能用在什么场景、开发成本多高、服务器费用多少。
选错协议 = 要么用户体验差（卡顿/延迟高），要么开发成本翻倍，要么服务器账单爆炸。
二、主流协议全维度对比表
| 维度 | HLS | DASH | HTTP-FLV | RTMP | WebRTC |
|---|
| 全称 | HTTP Live Streaming | Dynamic Adaptive Streaming over HTTP | FLV over HTTP | Real-Time Messaging Protocol | Web Real-Time Communication |
| 制定方 | Apple | MPEG 国际标准组织 | 社区（B 站推广） | Adobe（Flash 时代） | W3C / IETF |
| 延迟 | 10-30s（高） | 10-30s（高） | 1-3s（低） | 1-3s（低） | <1s（超低） |
| 兼容性 | ★★★★★ 全平台最优 | ★★★★ 需 JS 库 | ★★★ 需 flv.js | ★★ 推流端好，播放端差 | ★★★ 现代浏览器 |
| 是否支持点播 | ✅ | ✅ | ⚠️ 主要用于直播 | ❌ | ❌ |
| 是否支持直播 | ✅ | ✅ | ✅ | ✅（仅推流） | ✅ |
| 自适应码率 | ✅ 内置 | ✅ 内置（最强） | ❌ | ❌ | ⚠️ 需额外实现 |
| CDN 友好度 | ★★★★★ 标准 HTTP | ★★★★★ 标准 HTTP | ★★★★ HTTP 长连接 | ★★ 专用端口，CDN 贵 | ★ P2P，难用 CDN |
| 服务器成本 | 低（普通 HTTP CDN） | 低（普通 HTTP CDN） | 低（HTTP CDN） | 高（需专用流媒体服务器） | 中（需 TURN/STUN 服务器） |
| 技术难度 | ★★ 简单 | ★★★ 中等 | ★★★ 中等 | ★★★★ 复杂 | ★★★★★ 最复杂 |
| 前端播放依赖 | Safari 原生 / 其他浏览器需 hls.js | 需 dash.js 或 shaka-player | 需 flv.js / mpegts.js | 不用于播放端 | 浏览器原生 API |
| 清晰度上限 | 4K/8K 均可 | 4K/8K 均可 | 4K 可，无自适应 | 取决于推流端 | 通常 1080p |
| 典型使用者 | Apple TV+、抖音点播、大多数视频平台 | YouTube、Netflix、Bilibili 海外 | B 站直播、斗鱼 | OBS 推流、直播推流端 | Zoom、Google Meet、连麦 |
三、各协议优缺点详解
1. HLS — 最通用的选择
| 优点 | 缺点 |
|---|
| iOS/Android/PC 全兼容 | 延迟高（10-30s），不适合强实时 |
| CDN 分发成本最低（纯 HTTP） | 切片文件多，小文件 IO 开销大 |
| 内置多码率自适应 | 首次加载慢（需先下载 m3u8 再下载切片） |
| 生态最成熟，工具链最全 | |
一句话：不知道选什么就选 HLS，错不了。
2. DASH — 最灵活的标准
| 优点 | 缺点 |
|---|
| 国际标准，不受单一厂商控制 | iOS Safari 不原生支持 |
| 自适应码率算法最先进 | 需要 JS 库（dash.js），增加包体积 |
| 支持更多编码格式（H.265/AV1/VP9） | 配置复杂度高于 HLS |
| 支持 DRM 加密（Widevine/PlayReady） | |
一句话：追求极致画质+版权保护选 DASH（Netflix/YouTube 的选择）。
3. HTTP-FLV — 低延迟直播首选
| 优点 | 缺点 |
|---|
| 延迟低（1-3s） | 不支持 iOS Safari |
| 基于 HTTP，CDN 友好 | 不支持多码率自适应 |
| 实现相对简单 | FLV 格式老旧，未来趋势不明 |
| B 站验证过的大规模方案 | 无法做点播（不支持 seek） |
一句话：国内直播低延迟首选，B 站/斗鱼在用。
4. RTMP — 推流端的事实标准
| 优点 | 缺点 |
|---|
| 推流生态成熟（OBS/FFmpeg 直推） | 播放端已淘汰（Flash 已死） |
| 延迟低 | 需要专用流媒体服务器（Nginx-RTMP/SRS） |
| 协议成熟稳定 | 非 HTTP，CDN 成本高 |
| 防火墙/代理可能拦截 |
一句话：只用来推流，不用来播放。主播 OBS 推 RTMP → 服务器转 HLS/FLV 给观众。
5. WebRTC — 超低延迟实时通信
| 优点 | 缺点 |
|---|
| 延迟 <1s，接近实时 | 架构最复杂（ICE/STUN/TURN/SDP） |
| 浏览器原生支持，无需插件 | 大规模分发困难（P2P 不适合万人直播） |
| 支持双向音视频 | 服务器成本高（需 SFU/MCU） |
| 适合互动场景 | 画质/码率不如流媒体协议 |
一句话：视频通话/连麦/互动直播用它，纯观看不要用。
四、选型决策表
| 你的场景 | 推荐协议 | 理由 |
|---|
| 后台视频预览/点播 | MP4 直链 | 最简单，零成本 |
| 视频网站/长视频点播 | HLS | 兼容性最好，CDN 便宜 |
| 追求极致画质 + 版权保护 | DASH | 自适应码率 + DRM |
| 国内直播（秀场/游戏） | HTTP-FLV | 低延迟 + CDN 友好 |
| 海外直播/通用直播 | HLS 低延迟模式 | LL-HLS 延迟可降至 2-5s |
| 视频通话/连麦 | WebRTC | 唯一能做到 <1s 延迟的方案 |
| 主播推流 | RTMP | OBS 等工具只认 RTMP |
五、关注协议的核心原因总结
| 关注点 | 为什么重要 |
|---|
| 用户体验 | 延迟高 = 直播互动差；无自适应 = 弱网卡顿 |
| 成本 | RTMP 需专用服务器，WebRTC 需 TURN，HLS/DASH 用普通 CDN 最省钱 |
| 兼容性 | 选错协议 = iOS 用户看不了/需要额外 polyfill |
| 开发难度 | WebRTC 开发周期是 HLS 的 5-10 倍 |
| 业务场景 | 通话必须 WebRTC，点播用 HLS，没有万能方案 |
| 清晰度 | DASH 的 ABR 能保证最优画质，FLV 做不到动态切换 |
