1. 推流基础认知：从“把画面扔到网上”说起
各位好，我是老赵。做流媒体这行快十年了。今天咱们聊聊最基础的东西——推流、拉流、转码，还有那些绕不开的协议。
很多人一上来就问我：“赵哥，推流到底是个啥？” 说白了，就是把你在电脑或手机上录好的画面，实时地“扔”到服务器上去。你想想看，你开直播，摄像头拍到你的脸，这数据得先送到某个地方，别人才能看到。这个过程，就叫推流。
那拉流呢？就是观众从服务器上把画面“拿”下来看。一个推，一个拉，中间那个服务器就是中转站。
至于转码，嗯，这里要注意。你推上去的视频，可能格式很特殊，或者码率太高。服务器得把它转成各种设备都能看的格式。比如你推的是4K，但手机用户看1080p就够了，服务器就得实时转一下。我在项目中遇到过，有一次没配好转码，结果所有观众都卡成PPT，那叫一个惨。
直播 vs 点播：一个“现在进行时”，一个“过去完成时”
这两个概念，我建议你从一开始就分清楚。它们的技术栈完全不同。
| 对比维度 | 直播 | 点播 |
|---|---|---|
| 核心特点 | 实时性，延迟敏感 | 存储性，随时观看 |
| 数据来源 | 实时采集、编码、推送 | 预先录制、存储的文件 |
| 播放方式 | 线性播放，无法快进 | 支持拖拽、倍速、选集 |
| 典型场景 | 体育赛事、电商带货、在线教育 | 电影、电视剧、录播课程 |
| 技术难点 | 低延迟、抗丢包、高并发 | 存储成本、CDN分发、防盗链 |
你看，直播是“现在进行时”，画面过了就没了。点播是“过去完成时”，文件存在那，随时可以看。我个人习惯，做直播项目时，脑子里永远绷着一根“延迟”的弦；做点播项目时，则更关注“存储”和“分发”。
流媒体协议大乱斗：RTMP、HLS、SRT、WebRTC
协议这东西，是流媒体的灵魂。没有协议，数据就是一堆乱码。我刚开始学的时候，也被这些缩写搞得头晕。咱们一个一个捋。
RTMP（Real-Time Messaging Protocol）
这算是老前辈了。Adobe 搞出来的，最初是为了 Flash 播放器。现在虽然 Flash 没了，但 RTMP 在推流端依然很坚挺。为什么？因为它稳定，延迟低（3-5秒）。
- 优点：推流稳定，生态成熟，几乎所有编码器都支持。
- 缺点：基于 TCP，握手复杂，容易被防火墙拦截。而且浏览器端不支持原生播放。
- 我的经验：我曾经在一个跨国直播项目中，就因为客户那边的防火墙封了 RTMP 的 1935 端口，折腾了两天。最后没办法，只能改用 SRT。
HLS（HTTP Live Streaming）
苹果推出的协议，现在是点播和直播的“万金油”。它的核心思想是把视频切成一个个小片段（比如2秒一个），然后通过 HTTP 传输。浏览器和手机都原生支持，兼容性无敌。
- 优点：兼容性极好，穿墙能力强，支持自适应码率。
- 缺点：延迟高，传统 HLS 延迟在 10-30 秒。虽然现在有“低延迟 HLS”（LL-HLS），但配置起来比较麻烦。
- 避坑指南：我曾经为了追求低延迟，把 HLS 的切片时长设成了 0.5 秒。结果服务器压力暴增，CDN 节点缓存也出了问题。后来我学乖了，一般设 2 秒，配合 LL-HLS 的“部分片段”机制，延迟能压到 3-4 秒。
SRT（Secure Reliable Transport）
这是近年来非常火的一个协议。它基于 UDP，但通过内置的丢包重传机制，实现了类似 TCP 的可靠性。说白了，就是“又快又稳”。
- 优点：延迟低（1-2秒），抗丢包能力强，支持 AES 加密。
- 缺点：生态不如 RTMP 成熟，部分老旧编码器不支持。
- 我的建议：如果你做的是跨国直播，或者网络环境比较差（比如卫星、4G），我强烈建议你试试 SRT。它真的能救命。
WebRTC（Web Real-Time Communication）
这是谷歌主导的实时通信协议。它追求的是“毫秒级”延迟，主要用于视频会议、在线教育等场景。
- 优点：延迟极低（<500ms），浏览器原生支持，无需插件。
- 缺点：架构复杂，服务器端（SFU/MCU）部署成本高，大规模并发时压力大。
- 注意：WebRTC 虽然延迟低，但它的设计初衷是“一对一”或“小范围”通信。如果你要做万人直播，直接用 WebRTC 推流，服务器可能会崩。我建议你把它用在“连麦”或“互动”环节，主画面还是用 RTMP 或 HLS。
核心总结：
- 推流首选：RTMP（稳定）或 SRT（抗丢包）。
- 拉流首选：HLS（兼容性）或 WebRTC（低延迟互动）。
- 转码：是服务器端的“翻译官”，必不可少。
一张图看懂推流链路
下面这张图，是我自己画的。它展示了从推流到拉流的完整链路。你仔细看一遍，就能明白这些协议和组件是怎么配合的。
💡 我的小技巧： 在实际部署中，我通常会用 RTMP 推流到服务器，然后在服务器端转码成 HLS 和 WebRTC 两种格式。HLS 给普通观众，WebRTC 给需要互动的用户。这样既保证了兼容性，又兼顾了互动体验。
⚠️ 警告： 不要试图用 WebRTC 直接推流给上万人。它的架构设计就不是为了这个。我曾经见过一个团队，用 WebRTC 做万人直播，结果服务器 CPU 直接爆了。记住，WebRTC 是“互动”用的，不是“广播”用的。
好了，这一章的内容就到这里。你先把这些基础概念消化掉。推流、拉流、转码，还有那四个协议，它们是你后面所有操作的地基。地基不稳，楼盖得再高也得塌。