1. 流媒体基础概念
大家好，我是这门课的主讲。今天咱们聊聊流媒体最基础的东西。
什么是流媒体？说白了，就是「边下边播」。你不需要等整个视频文件下载完，就能直接看。我记得刚入行那会儿，还在用 RealPlayer 看在线视频，那时候网速慢，缓冲转圈是家常便饭。现在技术成熟多了，但核心逻辑没变——数据像水流一样，源源不断地从服务器推到你眼前。
1.1 什么是流媒体
流媒体（Streaming Media）是一种多媒体传输技术。它把音视频数据切成小块，按顺序发送。客户端收到一部分就开始播放，同时继续接收后面的数据。
这里有个关键点：实时性。传统下载是把文件整个拉到本地，你才能打开。流媒体不一样，它追求的是「低延迟启动」和「持续播放」。我做过一个直播项目，用户对延迟特别敏感，超过 3 秒就开始骂娘。嗯，这就是流媒体要解决的核心问题。
流媒体的三个核心特征：
- 边下边播——无需完整下载
- 实时传输——数据持续到达
- 自适应码率——根据网络状况动态调整
你想想看，如果没有流媒体，你看个 2 小时的电影，得先等 10 分钟下载完。这体验谁受得了？流媒体把等待时间压缩到了几秒钟，甚至更低。
1.2 流媒体协议概览
协议是流媒体的「语言」。不同场景用不同协议，选错了，项目就得翻车。我见过不少团队，上来就用 RTMP 做点播，结果兼容性一塌糊涂。
目前主流的协议有三个：RTMP、HLS、DASH。咱们一个一个说。
RTMP（Real-Time Messaging Protocol）
RTMP 是 Adobe 搞出来的，基于 TCP 的实时消息协议。它最大的特点就是延迟低，能到 1-3 秒。早期直播几乎全是它。
但 RTMP 有个硬伤——它依赖 Flash。现在浏览器基本都抛弃 Flash 了，所以 RTMP 主要用于推流端（编码器到服务器），播放端很少直接用。
我的经验：如果你做直播推流，RTMP 仍然是最稳的选择。我曾经用 RTMP 推流到 CDN，跑了半年没出过问题。但播放端一定要转成 HLS 或 WebRTC，别指望浏览器直接播 RTMP。
HLS（HTTP Live Streaming）
HLS 是苹果推出的，基于 HTTP 的流媒体协议。它把视频切成一个个小片段（通常是 2-10 秒），客户端通过 m3u8 索引文件来拉取这些片段。
HLS 最大的优势是兼容性好。所有主流浏览器、移动端都支持。而且它基于 HTTP，能轻松穿透防火墙和代理。
但 HLS 的延迟比较高，通常在 6-30 秒。为什么？因为它要等整个片段下载完才能播。你想想看，一个 6 秒的片段，客户端得先缓冲完才能开始播，延迟自然就上去了。
注意：HLS 的延迟问题在直播场景下特别明显。我做过一个体育直播项目，用户抱怨比分都出来了，画面还没到。后来我们用了低延迟 HLS（LL-HLS），把片段切到 1-2 秒，延迟降到了 3-5 秒，才算勉强能接受。
DASH（Dynamic Adaptive Streaming over HTTP）
DASH 是 MPEG 推出的国际标准，也叫 MPEG-DASH。它和 HLS 思路类似，也是切片段、基于 HTTP。但 DASH 更灵活，支持多种编码格式、多种 DRM 方案。
DASH 的延迟和 HLS 差不多，也在 6-30 秒。但它的自适应码率算法更成熟，能根据网络状况平滑切换清晰度。
我个人习惯用 DASH 做点播，HLS 做直播。为什么？DASH 在点播场景下的码率自适应更细腻，用户体验更好。但直播场景下，HLS 的生态更成熟，CDN 支持也更广泛。
| 协议 | 传输层 | 延迟 | 适用场景 | 兼容性 |
|---|---|---|---|---|
| RTMP | TCP | 1-3 秒 | 推流、低延迟直播 | 差（依赖 Flash） |
| HLS | HTTP/TCP | 6-30 秒 | 直播、点播 | 好（全平台） |
| DASH | HTTP/TCP | 6-30 秒 | 点播、自适应码率 | 较好（主流浏览器） |
1.3 C/S 架构与 P2P 架构对比
架构选型决定了系统的成本和性能。C/S 架构和 P2P 架构是两种截然不同的思路。
C/S 架构（Client-Server）
C/S 架构就是传统的客户端-服务器模式。所有数据都从中心服务器分发。优点是简单、可控、稳定。缺点是服务器带宽成本高，单点故障风险大。
我做过一个在线教育平台，用的是 C/S 架构。一开始用户少，服务器扛得住。后来用户涨到 10 万并发，CDN 带宽费用直接爆表。老板看着账单直摇头。
C/S 架构的典型场景：
- 小规模直播（< 1 万并发）
- 对延迟要求高的场景（如互动直播）
- 需要强管控的内容分发（如版权保护）
P2P 架构（Peer-to-Peer）
P2P 架构让客户端之间互相分享数据。每个客户端既是消费者，也是提供者。优点是带宽成本低，扩展性好。缺点是延迟高，稳定性差，NAT 穿透麻烦。
我曾经在一个视频点播项目里尝试过 P2P。用户越多，速度越快，服务器带宽成本降了 70%。但问题也来了——有些用户网络环境复杂，连不上其他节点，体验很差。后来我们做了混合架构，C/S 兜底，P2P 加速，才算平衡了成本和体验。
避坑指南：P2P 架构不适合直播场景。为什么？因为直播数据是实时的，P2P 的节点发现和数据同步需要时间，延迟会很高。我曾经试过用 WebRTC 做 P2P 直播，延迟到了 10 秒以上，用户全跑了。
| 维度 | C/S 架构 | P2P 架构 |
|---|---|---|
| 带宽成本 | 高（服务器承担全部流量） | 低（客户端分担流量） |
| 延迟 | 低（直接连接服务器） | 高（节点间转发） |
| 稳定性 | 高（中心化管控） | 低（依赖节点质量） |
| 扩展性 | 差（需要扩容服务器） | 好（用户越多越强） |
| 实现复杂度 | 低 | 高（NAT 穿透、节点管理） |
1.4 知识体系总览
下面这张图把本章的核心知识点串起来了。你可以看到流媒体的基本流程：从采集编码，到协议传输，再到客户端播放。架构选型决定了整个系统的形态。
从这张图你能看到，流媒体系统是一个完整的链路。采集、编码、协议、架构、播放，每个环节都有坑。我见过不少团队，只关注协议选型，忽略了编码和架构，结果系统上线就崩。