11、SFU服务器基础：SFU的概念、使用Mediasoup或Janus的思路、SFU的转发逻辑
聊到WebRTC的多人通信，就绕不开SFU这个核心概念。说白了，SFU就是解决“一群人视频通话，怎么让服务器不炸、客户端不卡”的关键方案。我个人习惯把SFU比作一个“智能分发中心”——它不处理视频内容，只负责把每个人的音视频流，按需转发给其他人。
什么是SFU？
SFU的全称是Selective Forwarding Unit，选择性转发单元。它的工作模式很简单：每个客户端把自己的音视频流推送到服务器，服务器根据房间里的订阅关系，把流转发给其他参与者。
举个例子：一个4人视频会议，A、B、C、D都在发言。SFU会收到4路流，然后分别转发给需要的人。A想看B和C，SFU就只把B和C的流发给A，D的流不发。这种“按需转发”大大节省了带宽和服务器资源。
核心要点：SFU不混流、不转码，只做包的复制和转发。这是它轻量、高效的根本原因。
我在项目中遇到过不少团队，一开始想用MCU（多点控制单元）做混流，结果服务器CPU直接拉满，延迟也高得离谱。后来换成SFU，问题迎刃而解。你想想看，MCU需要解码、混流、再编码，而SFU只是转发RTP包，这中间差了多少计算量？
Mediasoup vs Janus：选哪个？
目前主流的SFU开源方案，Mediasoup和Janus是绕不开的两个选择。我两个都用过，说说我的感受。
| 特性 | Mediasoup | Janus |
|---|---|---|
| 架构 | 纯SFU，专注转发 | 插件化，支持SFU、MCU等多种模式 |
| 性能 | 极高，C++底层，内存管理精细 | 较高，但插件层有一定开销 |
| 灵活性 | 高，可深度定制转发逻辑 | 中，插件机制限制了部分自定义 |
| 学习曲线 | 陡峭，需要理解底层RTP/RTCP | 平缓，文档和示例更丰富 |
| 适用场景 | 大规模直播、低延迟会议 | 需要快速集成、多功能的场景 |
我的建议：如果你追求极致性能，并且团队有C++功底，选Mediasoup。如果你需要快速出活，或者需要录制、转码等附加功能，Janus更合适。嗯，这里要注意，Mediasoup的API设计比较底层，你需要自己处理信令和房间管理，而Janus提供了更完整的解决方案。
个人经验：我曾经在一个在线教育项目中使用Mediasoup，因为我们需要支持千人同时在线，且延迟要低于200ms。Mediasoup的零拷贝转发机制帮了大忙。但如果你只是做一个小型会议系统，Janus的开箱即用体验会好很多。
SFU的转发逻辑
SFU的转发逻辑，说白了就是“谁想看谁，我就把谁的流发给谁”。但这里面有几个关键点需要搞清楚。
1. 订阅模型
每个客户端加入房间后，会告诉SFU它想看哪些流。这个订阅关系可以是动态的——比如用户切换画面、开启画中画，都会触发重新订阅。SFU维护一张订阅表，记录每个客户端的订阅列表。
// 伪代码：订阅逻辑
class SFU {
subscriptions: Map<string, Set<string>> = new Map();
subscribe(clientId: string, targetId: string) {
if (!this.subscriptions.has(clientId)) {
this.subscriptions.set(clientId, new Set());
}
this.subscriptions.get(clientId)!.add(targetId);
}
unsubscribe(clientId: string, targetId: string) {
this.subscriptions.get(clientId)?.delete(targetId);
}
forward(stream: RTPPacket, from: string) {
for (const [clientId, targets] of this.subscriptions) {
if (targets.has(from) && clientId !== from) {
this.send(clientId, stream);
}
}
}
}2. 带宽自适应
SFU需要根据客户端的网络状况，动态调整转发策略。比如，A的网络不好，SFU可以只转发B的流，暂时不转发C的流。或者降低B流的码率（如果SFU支持转码的话）。
我记得有一次做压力测试，客户端网络波动很大，SFU如果不做带宽自适应，直接导致所有流都卡顿。后来我们实现了基于REMB（远程估计最大比特率）的反馈机制，SFU根据客户端的接收端报告，动态调整转发优先级。
避坑指南：我曾经在带宽自适应上踩过一个坑——没有考虑客户端的上行带宽。如果客户端上行带宽不足，它推流就会卡顿，这时候SFU再怎么优化转发也没用。所以，一定要同时监控上行和下行的带宽状况。
3. 流切换与Simulcast
SFU的另一个重要能力是Simulcast（联播）。发送端同时推送多个分辨率的流（比如720p、480p、240p），SFU根据接收端的网络和屏幕大小，选择合适的分辨率转发。
举个例子：手机端看桌面端共享屏幕，SFU会转发低分辨率的流给手机，节省带宽。桌面端之间互看，则转发高分辨率流。
// Simulcast转发逻辑
function selectLayer(client: Client, streams: Stream[]) {
const bandwidth = client.bandwidth;
const screenSize = client.screenSize;
if (bandwidth > 2000 && screenSize > 1080) {
return streams.find(s => s.resolution === '720p');
} else if (bandwidth > 1000) {
return streams.find(s => s.resolution === '480p');
} else {
return streams.find(s => s.resolution === '240p');
}
}SFU的核心转发流程
下面这张图展示了SFU从接收到转发的基本流程。我习惯用这种图来跟团队沟通架构，一目了然。
从图中可以看到，发送端A、B、C各自推流到SFU。SFU根据接收端X、Y、Z的订阅关系，选择性转发。比如X订阅了A和B，SFU就把A和B的流发给X，C的流不发。这就是SFU最核心的“按需转发”逻辑。
实际项目中的选择思路
如果你现在要选一个SFU方案，我建议你按以下步骤来思考：
- 明确需求：多少人同时在线？延迟要求多少？需要录制吗？
- 评估团队能力：有C++高手吗？还是全员前端？
- 考虑扩展性：未来会不会增加功能？比如转码、合流？
- 测试性能：用模拟工具压测，看CPU和内存占用。
我的经验：如果你刚开始接触SFU，我建议先用Janus快速搭建一个原型，验证业务逻辑。等跑通了，再考虑是否迁移到Mediasoup追求极致性能。不要一上来就选最复杂的方案，容易把自己绕进去。
好了，关于SFU的基础概念、Mediasoup和Janus的选择思路，以及转发逻辑，就聊到这里。记住，SFU的核心就是“按需转发”，理解了这个，后面的实践就顺了。