多人通信架构：Mesh/MCU/SFU对比、SFU服务器选型、媒体转发原理

多人实时通信，说白了就是让一群人同时说话、同时看到对方。这跟一对一通话完全是两码事。一对一你只需要一条管道，但人一多，管道数量就爆炸了。我最早做视频会议系统时，就被这个“人数增长带来的复杂度”狠狠教育过。

今天咱们就聊聊多人通信的三种主流架构：Mesh、MCU、SFU。我会结合自己的踩坑经历，帮你理清它们的区别、适用场景，以及SFU服务器到底该怎么选。

一、三种架构的核心区别

先看一张图，帮你快速建立整体认知：

二、Mesh 架构：简单但有限

Mesh 是最直观的方案。每个客户端跟其他所有人直接建立 P2P 连接。4个人开会，每个人要维护3条连接。

优点很明显：

• 不需要服务器转发，成本低
• 延迟最小，因为是直连
• 部署简单，纯浏览器就能跑

缺点也很致命：

• 上行带宽 = (n-1) × 单流带宽。4个人每人上行3路，10个人就是9路
• 客户端编码压力大，手机根本扛不住
• NAT 穿透成功率随人数增加而下降

三、MCU 架构：服务器做“和事佬”

MCU（Multipoint Control Unit）是传统视频会议的老大哥。所有客户端把流发给服务器，服务器解码、混流、重新编码，再下发一路合成流。

你想想看，每个客户端只需要上行1路、下行1路，带宽压力最小。但代价是什么？

• 服务器要做解码 + 混流 + 编码，CPU 消耗巨大
• 混流后分辨率、码率统一，无法按需订阅
• 延迟增加，因为多了解码-编码环节

四、SFU 架构：当前的主流选择

SFU（Selective Forwarding Unit）是 MCU 的进化版。服务器不做混流，只做转发。每个客户端上行1路，服务器根据订阅关系，把对应的流转发给其他客户端。

说白了，SFU 就是个智能路由器。它知道谁想看谁的流，然后精确转发。

SFU 的核心优势：

• 服务器压力小，只转发不编码
• 客户端可以按需订阅，比如只看某几个人的大画面
• 支持 Simulcast（同时发送多路不同分辨率的流），接收端自适应
• 延迟低，只增加一次网络转发

SFU 的挑战：

• 下行带宽 = (n-1) × 单流带宽，对接收端有要求
• 需要实现订阅管理、流控制逻辑
• 服务器带宽消耗大（但比 MCU 的 CPU 消耗划算）

五、三种架构对比表

维度	Mesh	MCU	SFU
服务器成本	无	高（CPU密集）	中（带宽密集）
客户端上行	(n-1)路	1路	1路
客户端下行	(n-1)路	1路	(n-1)路
延迟	最低	较高	低
灵活性	差	差	高（按需订阅）
适用人数	3-4人	10-50人	10-1000人
典型场景	极小型会议	传统视频会议	现代WebRTC应用

六、SFU 服务器选型

如果你决定用 SFU，接下来就是选哪个实现。我列几个主流的，说说我的使用感受。

1. mediasoup

• C++ 实现，性能极高
• API 设计简洁，文档清晰
• 支持 Simulcast、SVC、DataChannel
• 我个人的首选。我在生产环境跑过 mediasoup，单机支持 200 路 720p 流，CPU 占用不到 30%

2. Janus

• C 语言实现，老牌项目
• 插件架构，功能丰富
• 配置稍复杂，学习曲线陡
• 适合需要录制、转码等附加功能的场景

3. LiveKit

• Go 语言实现，部署简单
• 提供完整的客户端 SDK
• 云原生，支持 Kubernetes
• 适合快速原型和中小规模应用

4. SRS

• 国人开发，文档中文友好
• 支持 RTMP、HLS、WebRTC 多种协议
• 适合直播 + 实时通信混合场景

七、媒体转发原理

SFU 的媒体转发，核心就三件事：接收、查找、发送。

1. 接收：客户端通过 ICE 连接，把 RTP 包发送到 SFU
2. 查找：SFU 根据 SSRC（同步源标识符）找到对应的流，再查订阅表，看哪些客户端订阅了这条流
3. 发送：把 RTP 包复制一份，转发给所有订阅者

听起来简单，但实际实现时有很多细节：

• NACK 处理：SFU 需要转发 NACK 请求，或者自己缓存包做重传
• 带宽估计：SFU 可以收集接收端的带宽信息，反馈给发送端调整码率
• Simulcast 切换：当接收端带宽变化时，SFU 可以自动切换到更低分辨率的流

八、总结

三种架构各有适用场景。Mesh 适合极小型会议，MCU 适合传统硬件视频会议，SFU 是当前 WebRTC 应用的主流选择。

我个人强烈建议新项目直接上 SFU。服务器成本可控，灵活性高，而且社区生态成熟。选型时优先考虑 mediasoup 或 LiveKit，具体看团队技术栈和需求。

媒体转发原理不复杂，但实现细节很多。建议先跑通一个 demo，再逐步深入优化。嗯，今天就聊到这里，希望这些经验对你有帮助。