1、推流基础：什么是推流？推流协议（RTMP、SRT、WebRTC）对比与选择

做直播的人，天天都在说「推流」。但真要问一句——推流到底是什么？

我见过不少刚入行的朋友，把推流理解成「开个软件点一下开始」。嗯，没那么简单。推流，说白了就是把你在摄像头、麦克风、屏幕采集到的音视频数据，经过编码压缩后，通过网络实时发送到服务器端的过程。

你想想看，一段 1080p 的原始视频，一秒钟的数据量可能高达几百兆。不压缩直接传？别说互联网了，内网都扛不住。所以推流的核心就两件事：编码压缩和网络传输。编码决定了画质的上限，传输协议决定了画质能保留多少。

1.1 推流的基本链路

我习惯把推流链路拆成四个阶段，这样排查问题的时候思路特别清晰：

1. 采集阶段：摄像头、麦克风、屏幕画面。注意采集分辨率、帧率要匹配你的推流目标。
2. 编码阶段：把原始音视频压缩成 H.264/H.265 + AAC。码率、编码档次、GOP 大小都在这里决定。
3. 封装阶段：把编码后的数据打包成 FLV、TS 或 MP4 容器。不同的协议用不同的封装格式。
4. 传输阶段：通过 RTMP、SRT、WebRTC 等协议把数据包发到服务器。

我曾经遇到过一个案例：用户说推流画质模糊，我一看，采集分辨率设的是 640×480，编码码率给了 8 Mbps。你想想看，分辨率本身就低，码率再高也救不了细节。这就是链路第一步就出了问题。

1.2 三大推流协议对比

现在主流的推流协议就三个：RTMP、SRT、WebRTC。每个协议都有自己的脾气，选错了，后面全是坑。

特性	RTMP	SRT	WebRTC
传输层	TCP	UDP + 自定义重传	UDP + ICE/SRTP
延迟	3-10 秒	0.5-2 秒	0.1-0.5 秒
抗丢包	弱（TCP 重传导致延迟飙升）	强（ARQ + FEC）	中（依赖 FEC + NACK）
推流端适配	OBS、FFmpeg、编码器	OBS、FFmpeg、SRT 编码器	浏览器、App SDK
典型场景	传统直播、CDN 分发	弱网环境、远程制作	实时互动、视频会议
复杂度	低	中	高

1.3 RTMP：老将，但还能打

RTMP 是 Adobe 在 2000 年代推出的协议，基于 TCP。说实话，它已经「老」了，但生态太强了。几乎所有 CDN、编码器、OBS 都支持 RTMP。你随便买个推流盒子，默认就是 RTMP。

RTMP 的缺点也很明显：TCP 的拥塞控制导致它在丢包环境下延迟会急剧上升。我曾经在东南亚一个项目里，网络丢包率 5%，RTMP 推流延迟直接飙到 30 秒以上。观众刷弹幕说「主播卡了」，其实主播那边一切正常，是 TCP 在拼命重传。

RTMP 推流地址格式很简单：

rtmp://push.example.com/live/streamkey

OBS 里填上这个地址，点开始推流，就完事了。但要注意：RTMP 默认只支持 H.264 编码，H.265 需要额外协商，很多 CDN 不支持。

1.4 SRT：弱网环境下的救星

SRT（Secure Reliable Transport）是 Haivision 开源的一个协议，基于 UDP。它最大的特点就是：在丢包环境下依然能保持低延迟。

SRT 用了 ARQ（自动重传请求）和 FEC（前向纠错）两种机制。简单说，丢包了它会智能地重传，但不会像 TCP 那样导致全局阻塞。我做过一个测试：在 10% 丢包率下，SRT 的延迟只增加了 500ms 左右，而 RTMP 已经没法看了。

SRT 的推流地址格式：

srt://push.example.com:10080?streamid=#!::r=live/streamkey,m=publish

注意那个 streamid 参数，里面包含了推流路径和模式。很多新手在这里栽跟头——忘了写 m=publish，结果连上了但推不出去。

1.5 WebRTC：实时互动的王者

WebRTC 是 Google 主导的实时通信协议，基于 UDP + ICE + SRTP。它的延迟能做到 100-500ms，适合视频会议、连麦、在线教育等场景。

但 WebRTC 推流有个大问题：它不是一个「推流协议」，而是一个「点对点通信协议」。你要做直播分发，需要先推到 SFU（Selective Forwarding Unit）服务器，再由 SFU 分发给观众。架构比 RTMP 复杂得多。

WebRTC 的推流流程大致是：

1. 浏览器/App 采集音视频
2. 通过 ICE 协议建立与 SFU 的连接
3. 使用 SRTP 加密传输音视频数据
4. SFU 转发给其他观众或录制服务

WebRTC 的码率控制是自适应的。它会根据网络状况动态调整编码码率。这个特性在弱网下很友好，但如果你想要稳定的画质，反而需要手动限制码率范围。

1.6 协议选择决策流程

说了这么多，到底怎么选？我画了一张决策图，你对着走就行：

这张图的核心逻辑就三点：

• 要超低延迟（<500ms） → WebRTC，但要做好 SFU 架构
• 网络差（丢包 >3%） → SRT，牺牲一点点延迟换稳定性
• 网络好，走 CDN → RTMP，省心省力

1.7 我的实战建议

做了这么多年推流，我总结了几条铁律：

• 不要迷信协议：协议只是工具，编码参数和网络质量才是画质的根本。你用 SRT 推 1Mbps 的流，画质照样不如 RTMP 推 8Mbps。
• 测试网络再选协议：我每次做项目，第一件事就是在推流点用 iperf3 测一下网络。丢包率、抖动、带宽，这三个指标直接决定协议选择。
• 留好备用方案：我曾经在一个大型活动里，RTMP 主推流突然断了，还好提前配了 SRT 备用链路，30 秒内切过去，观众几乎没感知。