「流媒体」的核心不是「流」，是「不等整个文件下完就开始播」。 为了做到这一点，发送端要能边读边发，接收端要能边收边解——这两件事决定了协议怎么设计。
前两节算的是「一秒钟要多少数据」，这一节开始问「这些数据怎么过去」。 传输方式的选择会反过来限制编码参数：要组播就得用能容忍丢包的编码， 要走 HLS 就得切成独立可解的片段。
一、下载后播与边下边播
最朴素的做法是「整个文件下完再播」，这叫下载后播。 它的优点是简单，缺点是等待时间等于文件大小除以带宽——一小时的 1080p 视频要下 313 GB（未压缩）， 或者几个 GB（压缩后），没人愿意等。
流媒体的做法是边下边播：播放器一边接收一边解码， 只要「已收到的数据比正在播的位置超前一点」就能播。 这个「超前一点」就是缓冲区，它是流媒体最核心的一个参数。
缓冲区的两难： 缓冲太短，网络一抖就卡——因为手里没有存货。 缓冲太长，起播慢、拖动响应慢——因为要先攒够这么多才开始。
所以播放器里那个「缓冲中」的圈，本质上是在赌：赌接下来几秒的网络能跟上。 赌输了就是卡顿，赌赢了就是流畅。
二、单播、组播、广播
这三个词说的是「一份数据在网络里被复制几次」。
| 方式 | 一份数据发给谁 | 复制在哪发生 | 地址形态 |
|---|---|---|---|
| 单播 | 一个确定的接收者 | 发送方网卡 | 目标地址是对方 IP |
| 组播 | 一群订阅了的接收者 | 路由器按需分叉 | D 类地址 |
| 广播 | 同一网段所有主机 | 交换机全端口 | 255.255.255.255 |
单播的成本是线性增长的：一千个人看，服务器就要发一千份。 组播的成本是常数：无论多少人在听，源端只发一份，复制发生在离观众最近的那个分叉点。
组播的账面上完胜，实际却几乎用不了，因为它要求从源到观众的每一台路由器都开组播路由（PIM、 IGMP）。 公网上跨运营商这一段没人愿意为你的流量开这些，所以组播只活在「自己管得着全程」的地方： 企业内网、运营商 IPTV、股票行情。
广播更局限：它不过路由器，只在一个网段内有效。 所以它只用于「找邻居」这类协议，比如 ARP 问「谁的 IP 是这个」。 拿广播送视频，等于让全楼的人都收你的快递。
三、点播与直播
这是另一个坐标轴，跟单播／组播正交。 点播（VOD）：内容事先存在那里，观众什么时候看都行，可以随意拖。 直播（Live）：内容正在发生，所有人的播放位置基本对齐，只能追不能超。
这两者的技术差别很大： 点播可以预先切好所有片段、预先生成多档码率，成本是存储。 直播必须现场转码、现场切片、现场分发，成本是算力与延迟。
所以直播的「延迟」是一个必须明确定义的指标：主播说话到观众听见，中间经过采集、编码、推流、 转码、分发、缓冲、解码、播放，每一段都加几十到几百毫秒。要压到一秒以内，等于每一段都要改方案。
四、推流与拉流
这两个词描述的是「谁主动发起连接」： 推流：采集端主动把数据送给服务器（主播 → 平台）。 拉流：播放端主动向服务器要数据（观众 ← 平台）。
方向决定了协议选型： 推流要稳、要能重连、要能容忍短暂断续，所以常用 RTMP 或 SRT。 拉流要能扛海量并发、要能被 CDN 缓存，所以常用 HTTP 系的 HLS、HTTP-FLV。
这两个方向常常用两套完全不同的协议，中间由服务器做转换。 这就是「为什么推流用 RTMP、播放用 HLS」不是矛盾，而是分工。
五、为什么 CDN 是必需品
单播的线性成本意味着「观众越多越贵」，而 CDN 把这个成本改成了「按距离」。 它的做法是把内容复制到离观众几十公里的边缘节点，观众连的是边缘，不是源站。
这一步解决的不只是带宽，还有延迟：光在光纤里每毫秒走两百公里，跨半个中国一个来回就是几十毫秒。 边缘节点把「跨省」变成了「同城」。
代价是「一致性」：同一个内容在几百个节点上，怎么保证观众看到的是同一版？ 直播靠「切片编号 ＋ 短缓存」，点播靠「刷新与回源」。 这也是为什么直播的延迟下不去——缓存时间不能设成零。
一句话总结这一节：流媒体省的不是带宽，是等待；而省等待的代价，是缓冲、是复制、是缓存。
六、动手 Demo：一千个人同时看，出口带宽是乘出来的
这段用一千个观众算单播与组播的差别，再说明为什么组播在公网上走不通。 没有真跑网络——这一节算的是账，账本身就足够说明问题。
viewers, rate = 1000, 4 # 一千人、每人 4 Mbps
print(viewers * rate) # 4000 Mbps
rows = ((u"单播", u"1000 份", u"服务器网卡", u"4000 Mbps"),
(u"组播", u"1 份", u"路由器按需复制", u"4 Mbps"),
(u"广播", u"1 份", u"交换机全端口复制", u"4 Mbps 但全网都收到"))
for a, b, c, d in rows:
T([a, b, c, d], [0, 0, 0, 0])
实跑输出：
--------------------------------------------------------------------
一千个人同时看，出口带宽是乘出来的
--------------------------------------------------------------------
**「单播」的意思是服务器给每个观众各发一份。**
**观众数涨十倍，出口带宽就涨十倍。**
1000 个观众 × 4 Mbps ＝ **4000 Mbps ＝ 4 Gbps**。
这就是为什么直播平台一定要用 CDN：单台服务器的万兆口一个人扛不住。
**换组播，同一个包在网络里只复制一次**：
方式 服务器发出 复制发生点 一千人时
--------------------------------------------------------------------
单播 1000 份 服务器网卡 4000 Mbps
组播 1 份 路由器按需复制 4 Mbps
广播 1 份 交换机全端口复制 4 Mbps 但全网都收到
**组播的账面上赢麻了，实际上很难用**：
它要求从服务器到观众之间的每一台路由器都开组播路由（PIM）。
跨运营商几乎谈不下来，公网上基本不通。
所以公网直播走的是「单播 ＋ CDN 边缘复制」，靠钱换掉组播没做到的事。
**组播真正活着的地方是企业内网与运营商 IPTV**——从机房到用户这一段是自己管的，
才是组播唯一能全程跑通的环境。
四 Gbps 这个数字是「出口」，不是「总流量」：观众的下载量加起来也是四 Gbps，只是摊在各自家里， 不构成瓶颈。
真正的瓶颈永远在最窄的那一段：服务器网卡、机房上联、运营商互联、观众家的宽带， 任何一段不够，其他地方再宽也没用。这就是为什么「链路带宽」要看端到端。
最后那条「广播」写得故意刺眼：账面上它只发一份、也只占 4 Mbps，但同一网段的所有机器都得收。 在拥塞的网络上，广播风暴能在几分钟内把整栋楼的网打死——这就是为什么交换机都默认开着广播风暴抑制。
30 秒实验
- 查一下你所在单位的一条出口带宽，算它能支撑多少个 4 Mbps 的观众。
- 再算：如果用组播，这条出口能支撑多少？（答案是「跟人数无关」）
- 想一想：为什么视频会议不用组播，却用 SFU 这种「服务器帮大家转」的方案？
常见误区
- 以为组播一定比单播省。 省的是源端和主干，但边缘那段如果只有一个人在听， 组播反而多花了路由开销。
- 把「点播」和「单播」混为一谈。 一个是内容的时间属性，一个是网络的复制方式， 两者正交——直播也可以用单播。
- 以为缓冲越长越稳。 缓冲越长起播越慢、拖动越迟钝，而且它只是把「卡顿」推迟，不能消除。
自测三问（点开对答案）
1. 一千个人看 4 Mbps 的直播，用单播需要多大出口？ —— 4 Gbps。这是线性的，人数翻十倍带宽也翻十倍。 2. 组播为什么在公网上几乎用不了？ —— 它要求路径上每一台路由器都开组播路由，而公网跨运营商这一段没有人愿意为陌生流量开这些协议。 3. 为什么推流和播放常常用两套不同的协议？ —— 因为需求不同：推流要稳、要能重连，播放要能扛海量并发、要能被 CDN 缓存。中间由服务器做转换。把这几条路具体下来，就是几个有名字的协议——下一节逐个说 RTMP、RTSP、HLS、HTTP-FLV、 WebRTC 各自站在哪一格。
- ☐ （本节完，下一节 01.02.02 常见的流媒体协议）