推流基础认知：什么是推流、拉流与转码
各位同学好，我是老周。今天咱们正式开始《从零搭建稳定推流管线》的第一章。说实话，我见过太多人一上来就捣鼓 OBS、FFmpeg，结果直播卡成幻灯片，还不知道问题出在哪。说白了，就是没搞懂最基础的概念。
这一章，咱们把地基打牢。我会用最直白的方式，把推流、拉流、转码这几个核心概念讲清楚，再带你看看主流的直播协议，最后给你一张完整的推流管线全貌图。嗯，看完你就知道整个直播链路长什么样了。
1.1 推流、拉流与转码——直播的三板斧
先问个问题：你在 B 站看直播，主播那边在打游戏，你这边能看到画面，这中间发生了什么？
其实就三步：推流 → 转码 → 拉流。
推流（Publishing / Ingest）
推流，就是把主播端的音视频数据，实时地发送到服务器。你可以把它想象成「寄快递」——主播把画面和声音打包好，通过快递（网络）寄到服务器这个中转站。
我早期做项目时，遇到过推流端 CPU 飙到 90% 的情况，画面一卡一卡的。后来发现是编码器没选对，软编码扛不住。所以推流端的关键指标就两个：编码效率和网络稳定性。
拉流（Playback / Subscribing）
拉流，就是观众从服务器获取音视频数据。还是那个快递的比喻——观众去中转站取包裹。拉流端最怕什么？缓冲。我记得有一次线上演唱会直播，观众反馈画面每隔 10 秒转圈圈，查了半天是 CDN 节点没预热，拉流请求全打到源站去了。
转码（Transcoding）
转码，是服务器把主播推上来的流，转换成不同分辨率、码率、编码格式的版本。为什么要转码？因为观众的网络条件千差万别。有人用 5G 看 4K，有人在地铁上用 4G 看 480p。服务器得把一份源流，转成多份不同规格的流，让观众按需选择。
一句话总结：推流是上传，拉流是下载，转码是中间加工。三者缺一不可。
1.2 直播协议概览——选对协议，事半功倍
协议这东西，说白了就是推流和拉流时，数据怎么打包、怎么传输的规则。我见过不少新手，上来就用 RTMP 推流，然后用 HLS 拉流，结果延迟 10 秒以上，还以为是网络问题。其实，协议选错了。
下面这张表，是我这些年总结的协议对比，你直接拿去用：
| 协议 | 传输层 | 延迟 | 主要用途 | 我的评价 |
|---|---|---|---|---|
| RTMP | TCP | 1-3 秒 | 推流（主流） | 推流首选，但拉流体验差 |
| HLS | HTTP | 6-30 秒 | 拉流（兼容性好） | 苹果系标配，延迟高 |
| HTTP-FLV | HTTP | 2-5 秒 | 拉流（Web 端） | 延迟低，但移动端支持差 |
| WebRTC | UDP | < 1 秒 | 实时互动 | 延迟最低，但架构复杂 |
RTMP（Real-Time Messaging Protocol）
RTMP 是 Adobe 搞出来的老协议，但至今仍是推流界的「扛把子」。为什么？因为它基于 TCP，稳定可靠，而且几乎所有编码器（OBS、FFmpeg）都原生支持。我个人的习惯是：推流只用 RTMP，除非有特殊需求。
但 RTMP 有个致命伤——它用的是非标准端口（1935），很多企业防火墙会拦。所以实际部署时，我通常会在 RTMP 外面包一层 RTMPT（RTMP over HTTP），走 80 端口绕过防火墙。
HLS（HTTP Live Streaming）
HLS 是苹果推出的协议，现在已经是拉流的事实标准了。它的原理是把视频切成一个个小片段（通常是 2-10 秒的 .ts 文件），然后通过一个 .m3u8 索引文件来播放。好处是兼容性极好，几乎所有浏览器和手机都支持。坏处是延迟高——至少 6 秒起步。
我曾经做过一个教育直播平台，要求延迟在 3 秒以内。一开始用 HLS，延迟死活降不下来。后来换成 HTTP-FLV，问题才解决。所以，对延迟敏感的场景，慎用 HLS。
HTTP-FLV
HTTP-FLV 就是把 FLV 格式的音视频数据，通过 HTTP 传输。它比 HLS 延迟低（2-5 秒），而且可以复用现有的 HTTP 基础设施。但它的缺点也很明显：移动端支持差，iOS 上的 Safari 不支持 FLV 播放，得用 MSE（Media Source Extensions）来解。
WebRTC
WebRTC 是实时通信的终极方案。它基于 UDP，延迟可以做到 500 毫秒以内。但代价是架构复杂——你需要部署 STUN/TURN 服务器来处理 NAT 穿透，还要自己实现信令服务。我建议：只有做视频会议、在线教育等强实时场景，才考虑 WebRTC。
我的选型建议：
- 推流：RTMP（没有之一）
- 拉流（Web 端）：HTTP-FLV（低延迟）或 HLS（兼容性）
- 拉流（移动端）：HLS（首选）
- 实时互动：WebRTC
1.3 推流管线全貌——一张图看懂直播链路
好了，概念和协议都讲完了。现在咱们把整个推流管线串起来。下面这张 SVG 图，是我亲手画的，它展示了从主播端到观众端的完整链路。
这张图你看懂了吗？我来拆解一下：
- 推流端：主播的摄像头和麦克风采集音视频，经过编码器压缩（通常是 H.264 视频 + AAC 音频），然后通过 RTMP 协议推送到源站。
- 源站/边缘节点：服务器收到推流后，会做两件事——一是转码，把源流转成多码率版本（比如 1080p、720p、480p）；二是协议转换，把 RTMP 转成 HLS 或 HTTP-FLV，方便拉流。
- CDN 分发：转码后的流会被分发到 CDN 的边缘节点。观众拉流时，会从最近的 CDN 节点获取数据，减少延迟。
- 拉流端：观众通过播放器（Web 或 App）拉取流，解码后渲染到屏幕上。
避坑指南：我曾经在一个项目中，把转码和 CDN 部署在同一台服务器上。结果推流量一上来，CPU 直接打满，转码队列堆积，导致直播延迟飙升到 30 秒。后来我把转码服务独立部署到 GPU 服务器上，问题才解决。所以，转码一定要和 CDN 分离部署，别图省事。
1.4 本章小结
好了，第一章的内容就这些。咱们回顾一下重点：
- 推流是上传，拉流是下载，转码是中间加工。
- RTMP 是推流首选，HLS 是拉流兼容性之王，HTTP-FLV 适合低延迟 Web 场景，WebRTC 用于实时互动。
- 推流管线的完整链路是：推流端 → 源站（转码）→ CDN → 拉流端。