WebRTC SFU与MCU架构

可视化演示

展示SFU选择性转发、MCU混流编解码、流量模型对比及GCC拥塞控制与Simulcast多码率切换，含星座网络背景和发光动画。

架构总览：中转站与中央厨房

你开了一家外卖公司，需要把后厨做好的菜送到顾客手中，面前有两条路线：要么建一个骑手中转站，骑手取餐后原样送达，不拆封、不改味；要么建一个中央厨房，把大家点的菜汇到一起，由大厨重新烹饪成一桌统一的流水席再分送。WebRTC 的服务器架构也恰好分这两派，名字拗口，但本质就是“转”与“炒”的差别。

SFU（Selective Forwarding Unit，选择性转发单元）收到某位参会者的视频流后，不解码、不重编码，直接复制转发给其他所有参会者。MCU（Multipoint Control Unit，多点控制单元）则相反：先把所有人的视频都收进来，经过解码、画面拼合与混合布局，再重新编码成一路新的视频流，统一分发给每个人。两者的工作流程天然决定了后续的流量与算力分布：SFU 是“原样转手”，MCU 是“加工重组”。

理解了这两套“人力配置”的分野，后面所有的成本模型与选型逻辑都顺理成章：中转站的核心成本在配送通道，中央厨房的核心成本在灶台人力。

流量模型：单份配送与平方爆炸

中转站每新增一位顾客，就意味着每道菜都要额外多送一份——送餐单量像滚雪球一样膨胀；中央厨房则不管外面有多少桌，后厨始终只出一份统一的“合家欢大拼盘”，只是按桌分份而已。这个直觉正是 SFU 与 MCU 流量模型的缩影。

假设会议有 $N$ 人参会，每路视频的上行码率为 $b$。SFU 模式下，每个人上行 1 路，服务器需要把这一路复制给其余 $N-1$ 人，所以服务器下行总量为 $N(N-1)b$，当 $N$ 较大时接近 $N^{2}b$——这便是常说的“平方爆炸”。MCU 模式下，每个人仍然上行 1 路，但服务器混合后只输出 1 路码流（码率记为 $b_{mix}$，通常约等于单路码率），下行总量为 $N \times b_{mix}$——线性温和地增长。

中转站每多一个顾客，骑手要额外多跑许多趟；中央厨房每多一桌，后厨只多分一份拼盘。搞清楚谁在按平方扩张，你就知道服务器带宽预算该按什么曲线采购。

服务器负载：骑手与厨师的成本

中转站省钱省在“没有厨房”，但仓库的货架（带宽出口）需要堆满同样规格的餐盒；中央厨房省在“不用重复送餐”，但厨师团队（CPU/GPU）必须一刻不停地颠勺。到了服务器侧，两种架构的资源账单截然不同。

SFU 不转码，CPU 主要用于 RTP 包的转发、路由、统计与 NAT 穿透辅助，每个转发链路的开销很小；MCU 则每路流都要解码、参与混合布局、再重新编码，每一步都是重度计算。结果就是：MCU 的计算成本与参会人数 $N$ 线性相关，但系数极大；SFU 的计算成本同样随 $N$ 增长，但系数的量级远小于编解码。

预算有限时，开中央厨房要把钱花在雇更多厨师（算力），开中转站要把钱花在租更大的冷库与配送通道（带宽）。看懂这张账单，才知道钱该往哪边倾斜。

拥塞控制：谁在喊停车

雨天路滑，外卖车队遇上了堵车。中转站的做法是让每个骑手自己观察路况、自行减速；中央厨房的做法则是调度台统一发布指令：所有车降速、统一重新规划路线。WebRTC 的拥塞控制，也分这两种哲学。

在实际信道中，丢包率 $p_{loss}$ 是衡量拥塞的核心信号。发送端通过 RTCP 反馈（REMB / TWCC）感知丢包与延迟变化，并据此调整发送码率。SFU 架构下，服务器只做转发，带宽探测与码率决策基本发生在端侧：每个发送端根据接收端反馈的丢包率自行降速，反应快但不一定协调。MCU 架构下，服务器掌握全局接收情况，可在混合前统一决定“全员降码率”或“只保留音频”，集中调度一致性更强，但多了一道决策延迟。

中转站的路况由每个骑手自行判断，反应快但步调不一；中央厨房由调度台统一指挥，整齐划一但多了一层指挥延迟。拥塞控制的设计取舍，本质就是“分散自治”与“集中调度”的权衡。

选型决策：开站还是开厨房

开店之前先看客流量：如果每天只有三五桌客人，开中央厨房显然是浪费，一个小档口加几个骑手足矣；如果要做千人大食堂，就必须建中央厨房统一出餐，或者设计“多窗口 + 统一打菜”的混合动线。SFU 与 MCU 的选型，同样取决于规模、网络与预算三个变量。

小型固定会议（如 4～10 人）对统一画质、录制与管控有较高要求，MCU 的“一份拼盘”模式简单可靠。中大型会议一旦超过某个临界规模，$N^{2}$ 的带宽压力会迅速击穿机房预算，SFU 成为事实主流。更常见的工程实践是混合架构：主讲人上行给 SFU，观众只收不发，再通过“N 选 1 转推 CDN”把主流推到海量观众，从而把服务器出口从平方级降到线性级。

小馆子请一位大厨兼前台绰绰有余，万人食堂必须让大部分客流走“只看一份菜单”的快餐线。选型没有绝对优劣，只有客流量（规模）、路况（网络）与预算（成本）的匹配。

实践参考：市面上的外卖平台与中央厨房

想省心省力，可以直接租用别人建好的中转站（开源 SFU）或中央厨房（云厂商 MCU），不必从零砌灶台。工程团队的核心任务，是判断哪种“配送体系”适合自己。

mediasoup 是 Node.js 生态的 SFU 核心库，灵活嵌入自研服务，适合有定制需求的团队；Jitsi Videobridge 是久经考验的 SFU 实现，自带完整会议套件，生产可用性高；LiveKit 提供云原生 SFU 平台，REST API 与客户端 SDK 齐全，是快速上车的选择。云厂商（腾讯云、声网等）内部常为 SFU/MCU 混合架构，对外提供“单流上行 + 转推 CDN”的能力，把超大规模分发的成本转移给 CDN 流量包。

多数团队不会真的自建骑手军团或中央厨房——他们会把部分路段包给外卖平台（CDN），把部分菜品外包给云厂商（云 MCU）。理解了 SFU 与 MCU 的流量与算力本质，你才能理性评估：自己该租哪条配送线路、该租多少容量。

AI 应用场景

Python 演示

"""SFU vs MCU 带宽与成本模拟器"""  def sfu_traffic(n, b):    """SFU 流量模型：每路上行1份，服务器下行转发N-1份"""    up = n * b    down = n * (n - 1) * b    return up, down, up + down  def mcu_traffic(n, b, b_mix):    """MCU 流量模型：每路上行1份，混合后下行统一1份"""    up = n * b    down = n * b_mix    return up, down, up + down  def main():    print("人数  SFU总流量  MCU总流量  MCU省流量")    for n in [4, 8, 16, 32, 64]:        b = 1.0        b_mix = 1.0        _, _, sfu_total = sfu_traffic(n, b)        _, _, mcu_total = mcu_traffic(n, b, b_mix)        saving = (1 - mcu_total / sfu_total) * 100        print(f"{n:>4} {sfu_total:>9.1f} {mcu_total:>10.1f} {saving:>9.1f}%")  if __name__ == "__main__":    main()

1. def sfu_traffic(n, b):定义 SFU 流量模型函数，输入人数与单路码率。
2. down = n * (n - 1) * bSFU 下行核心公式：每路源被复制给其余 N-1 人，这是平方爆炸的根源。
3. def mcu_traffic(n, b, b_mix):定义 MCU 流量模型函数，混合码率通常取单路码率。
4. down = n * b_mixMCU 下行线性公式：只有一路混合流，按人数线性分發。
5. saving = (1 - mcu_total / sfu_total) * 100计算 MCU 相对 SFU 节省的带宽百分比。
6. for n in [4, 8, 16, 32, 64]:从 4 人到 64 人逐步放大规模，观察节省比例趋近 100%。

常见误区

面试题