Video 协议选型：MP4、HLS、DASH、HTTP-FLV、WebRTC 怎么讲清楚？
0. 面试速答（30 秒版 TL;DR）
- 先别把“视频协议”只理解成一个缩写，工程里至少要分清 3 层：封装格式、传输方式、播放接入能力。
- 最常见的 Web 点播方案不是“万能协议”，而是按场景选：简单点播优先 MP4，通用自适应点播优先 HLS，标准化多端分发可看 DASH，低延迟直播常见 HTTP-FLV / LL-HLS，强互动场景才会走 WebRTC。
- 前端选型核心不是“能不能播”，而是：浏览器原生支持、首帧速度、seek 体验、多码率、自适应、延迟、兼容性、排障成本。
- 一句话记忆：MP4 偏简单文件播放，HLS / DASH 偏切片分发，HTTP-FLV 偏低延迟直播，WebRTC 偏实时互动。
1. 先建立心智模型：协议不是一层，是一整条播放链路
很多人回答视频协议时，直接说“我们用 HLS”或者“我们用 MP4”。这不够准确。
对前端来说，至少要拆成下面几层：
- 编码层（Codec）：例如 H.264、H.265、AV1、AAC、Opus。
- 封装层（Container）：例如 MP4、TS、fMP4、WebM。
- 分发层（Delivery）：整文件、分片、长连接、实时传输。
- 播放器接入层：原生
video、MSE、hls.js、dash.js、FLV 播放器、WebRTC SDK。
如果这几层不分开，讨论协议选型就会越来越乱。比如：
MP4更像一个常见封装和文件分发方案。HLS是一套播放清单 + 分片分发方案，底层片段可能是TS或fMP4。WebRTC不是“拿来替代 MP4 的点播协议”，它面向的是低延迟实时传输。
2. 先按业务拆：点播、直播、互动直播，不是一套解法
2.1 普通点播
目标通常是：
- 接入简单
- 成本可控
- 首帧不要太差
- 拖动和续播稳定
这类场景优先考虑：
MP4 + CDN + 原生 videoHLS或DASH做多码率自适应点播
2.2 通用直播
目标通常是：
- 连续播放
- 延迟控制在可接受范围
- 大规模分发成本合理
这类场景常见：
HLSLL-HLSHTTP-FLV
2.3 强互动场景
目标通常是：
- 超低延迟
- 双向音视频
- 弱网下快速调节
这时才更常用：
WebRTC
面试里最容易扣分的一句是：“直播也可以直接 MP4 播。”这说明没有按业务目标拆问题。
3. 常见 Video 协议怎么理解
3.1 MP4
MP4 最适合拿来讲“简单点播”。
特点：
- 浏览器原生支持好
- 接一个 URL 就能播
- 工程接入成本最低
局限：
- 多码率自适应能力弱
- 长视频拖动体验依赖服务端
Range - CDN 缓存和切片治理没有 HLS / DASH 灵活
适用：
- 后台系统
- 简单课程回放
- 体量不大、链路不复杂的点播页
3.2 HLS
HLS 可以理解为“清单文件 + 小分片”方案。
特点：
- 很适合 CDN 分发
- 支持多清晰度和 ABR（Adaptive Bitrate）
- Safari 生态天然友好
局限：
- 非 Safari Web 端通常要配合
hls.js - 比简单 MP4 接入更复杂
- 分片长度、首片大小、关键帧布局都会影响首帧和拖动体验
适用：
- 课程平台
- 视频网站
- 通用点播
- 对清晰度切换和弱网体验有要求的场景
3.3 DASH
DASH 和 HLS 在思路上相近，也强调分片和多码率。
特点：
- 标准化程度高
- 在多终端和标准播放器体系里常见
- ABR 能力成熟
局限：
- Web 前端的通用性和生态认知度通常不如 HLS
- 团队缺少经验时，排障成本可能更高
适用：
- 有标准化多端播放需求
- 已有成熟 DASH 平台链路
3.4 HTTP-FLV
HTTP-FLV 更偏“低延迟直播播放”。
特点：
- 延迟通常低于传统 HLS
- 服务端持续推流，前端持续消费
局限：
- 浏览器通常需要 MSE 或播放器库兜底
- 长时间播放、内存治理、断流重连都更考验播放器实现
适用：
- 对延迟有要求的直播场景
- 互动性比普通直播更强，但又没到 WebRTC 那种实时级别
3.5 WebRTC
WebRTC 要放在“实时互动”框架里理解，不要和普通点播混答。
特点：
- 延迟最低
- 原生支持双向传输
- 很适合连麦、会议、互动课堂
局限：
- 服务端架构复杂
- NAT 穿透、带宽估计、弱网策略都更难
- 成本、监控、排障门槛更高
适用：
- 音视频会议
- 在线连麦
- 强互动直播
4. 前端选型时真正关心的维度
| 维度 | MP4 | HLS | DASH | HTTP-FLV | WebRTC |
|---|---|---|---|---|---|
| 接入复杂度 | 低 | 中 | 中 | 中高 | 高 |
| 浏览器原生能力 | 高 | Safari 高 | 一般 | 一般 | 较高 |
| 多码率自适应 | 弱 | 强 | 强 | 一般 | 动态但复杂 |
| 首帧速度 | 简单场景快 | 依赖首片与清单 | 依赖实现 | 通常较快 | 很快 |
| seek 体验 | 依赖 Range | 较好 | 较好 | 通常不是重点 | 通常不是重点 |
| 直播延迟 | 不适合 | 中高 | 中高 | 低 | 很低 |
| 工程治理成本 | 低 | 中 | 中高 | 中高 | 高 |
一个很实用的回答方式是：
- 如果只是普通点播，先从
MP4开始。 - 如果需要 ABR、多清晰度、长视频拖动体验，优先
HLS。 - 如果是低延迟直播，考虑
HTTP-FLV或LL-HLS。 - 如果是互动连麦，优先
WebRTC。
5. 一个标准答法：为什么有时不用 MP4，要改成 HLS？
可以这样回答：
MP4 对简单点播足够友好，但当视频变成长视频、多清晰度、弱网自适应、复杂 CDN 分发场景时，整文件模型就不够灵活。HLS 把媒体拆成清单和分片，前端可以按网络状况切换码率，CDN 也更容易缓存热点片段，所以更适合大规模点播平台。
这里真正体现的是工程权衡：
- 不是 MP4 不能播，而是治理能力不足。
- 不是 HLS 天然更高级，而是它更适合复杂视频业务。
6. 常见追问
6.1 为什么同一个 HLS，在 Safari 能播，在 Chrome 不能原生播？
因为 Safari 对 HLS 的原生支持更完整，而很多 Chromium 浏览器并不直接原生解 HLS 清单，需要前端通过 hls.js 把分片拉下来，再通过 MSE 喂给 video。
6.2 为什么长视频用 MP4 拖动经常不顺？
核心原因通常不是“前端写得差”，而是链路设计问题：
- 服务端是否支持
Range moov位置是否合理- 关键帧间隔是否过大
- CDN 是否正确缓存分段请求
6.3 为什么低延迟直播不直接全站 WebRTC？
因为 WebRTC 虽然低延迟，但它的服务端成本、网络复杂度、监控治理难度都更高。很多业务并不需要“几百毫秒级实时”，这时 HTTP-FLV 或 LL-HLS 更务实。
7. 容易讲错的地方
- 不要把 编码格式 和 播放协议 混为一谈。
- 不要把 点播方案 和 互动实时方案 混为一谈。
- 不要说“浏览器都支持 HLS”，这在 Web 端并不成立。
- 不要说“有播放器 SDK 就说明协议问题解决了”，SDK 只是播放器接入层，不等于链路治理完成。
8. 速记版
MP4：简单点播优先。HLS：通用点播和通用直播最常见。DASH：标准化强，Web 生态认知度略弱于 HLS。HTTP-FLV：低延迟直播常见折中方案。WebRTC：实时互动首选，但成本最高。- 答题顺序最好固定成：业务目标 -> 延迟要求 -> 自适应能力 -> 浏览器兼容 -> 工程成本。