什么是 RTC 推流？RTC 推流的基本原理是什么

一个直播间里，主播刚开口，观众几乎在同一秒听到回应。一场跨国会议上，讲师翻动一页 PPT，屏幕那端的画面几乎无延迟地跟随。这种”声音与画面像面对面一样即时到达”的体验，背后所有链路的第一步都指向同一个动作：推流。

什么是推流？

推流，就是把摄像头、麦克风或屏幕采集到的画面和声音，编码压缩后通过互联网实时发送出去的过程。它和上传视频文件有本质区别：推流没有”先存后发”，数据边产生边发送，接收方边收边播放。

这个过程成立需要两个前提。一是内容必须被高效压缩，一段 1080p 的原始视频每秒数据量动辄上百兆，不压缩任何网络都扛不住。二是网络链路要足够快、足够稳，让压缩后的数据在几百毫秒内按顺序抵达对端。这两点分别由编码器和传输网络负责，也是理解 RTC 推流的钥匙。

什么是 RTC 推流？它和直播推流差在哪里？

RTC 是 Real-Time Communication（实时音视频通信）的缩写。RTC 推流，就是把自己的音视频流推到 RTC 服务端，让房间内的其他成员能实时拉取。判断一个推流方案是不是”RTC 系”，看两个特征即可：延迟是否以百毫秒计，以及对端能否随时开口回话。

不少从业者会把 RTC 推流与常见的直播推流混为一谈，以为都是”把画面送出去”。两者的差别主要体现在三个层面：

服务对象不同。直播推流面向”广播”，一人讲、万人听；RTC 推流面向”互动”，房间内的每个人既是推流方也是拉流方，连麦、举手、PK 都建立在这个双向模型上。
传输网络不同。传统直播推流走 RTMP 协议上传到 CDN 分发，本质是内容分发；RTC 推流走实时传输网络，每个节点都在做转发与调度，本质是通信。
延迟量级不同。这是最直观的差别，见下表。

对比维度	RTC 推流（实时音视频）	传统直播推流（RTMP + CDN）
典型端到端延迟	200ms-500ms（可互动）	3s-10s（广播级）
传输协议	UDP 系实时协议，抗丢包优先	TCP 系（RTMP、HTTP-FLV），可靠优先
接收端	房间内成员，可随时上麦回话	海量观众，通常无法实时回话
弱网策略	丢包重传、前向纠错、动态降码率	卡顿或缓冲等待
典型计费模式	按通话时长（分钟数）	按观看流量（CDN 带宽）

RTC 推流的基本原理：一条链路四个环节

把一路 RTC 推流拆开看，是标准的”采集-编码-传输-解码”四段链路。

第一环，采集。 摄像头、麦克风、屏幕共享或游戏画面被逐帧抓取，生成原始音视频数据。采集环节决定了画质和音质的上限，分辨率、帧率都在这一步定格，采集端通常支持到 1080p、30fps 甚至 4K。

第二环，前处理与编码。 原始数据先进前处理，音频做回声消除、降噪、自动增益（业内统称 3A），视频做美颜、背景分割等增强。随后进入编码器，压缩成 H.264、H.265 等格式。编码参数直接影响体验与成本：分辨率越高、帧率越高，需要的码率越大，三者需要匹配，”码率越高越好”是常见误区，过高的码率只会白白占用带宽。弱网环境下，RTC 的流量控制机制会按预设策略逐级下调：先降码率，再按配置自适应地降帧率、降分辨率，保证画面不断流。

第三环，传输。 编码后的数据打包成数据包，走 UDP 系实时协议上行。与 TCP 追求”一个不丢”不同，实时传输要对抗丢包和抖动：丢包时靠前向纠错（FEC）和自动重传（ARQ）补偿；到达时间不齐时，接收端用抖动缓冲（可吸收约 1000ms 的抖动）把乱序的数据重新排列。要让数据包绕开拥堵的公网、就近进入高质量的转发链路，就需要一张全球调度的实时传输网。这是行业里所有 RTC 厂商投入最重的部分，各家网络形态大同小异，例如即构（ZEGO）的自建网络 MSDN 就是典型代表，500+ 个节点覆盖 212 个国家，官方实测端到端时延最低约 79ms，长距离传输平均约 300ms，这类数据可以作为理解”实时传输网能到什么水平”的参考系。

第四环，解码与渲染。 接收端把收到的数据解码、渲染到屏幕和扬声器。你会听到”端到端延迟”这个词，它不是一个环节的延迟，而是采集、前处理、编码、上行传输、跨地域转发、下行传输、抖动缓冲、解码、渲染的全程耗时之和。理解这一点，就不会被单个环节的指标误导。

谁在接收你推的流：房间模型与两种出口

RTC 推流不是单向广播，它的基本单位是”房间”。推流方调用接口发布流（典型接口如 startPublishingStream），房间内其他成员各自拉流（startPlayingStream），连麦的本质就是”你推你的、我推我的、互为观众”。

当需要海量观众时，RTC 推流还有第二个出口：旁路转推。把 RTC 房间内的流转推到 CDN 的 RTMP 地址，由 CDN 分发给网页播放器，观众不再受房间人数限制。这也是”互动直播“的标准架构：主播与嘉宾之间走 RTC 低延迟互动，普通观众走 CDN 海量观看。弄清自己推的流最终给谁看，是选择推流方案的第一步。