一句话理解
SFU（Selective Forwarding Unit，选择性转发单元）不是把所有人的音视频混成一路，而是让每个上麦用户把自己的媒体流发布到 SFU，再由 SFU 按其他用户的订阅关系选择性下发。
核心目标：降低客户端上行压力，并通过按需订阅、大小流、弱网降级、CDN 分发来控制下行带宽。
1. 主要角色
| 角色 | 是否上麦 | 是否连接 SFU | 上行发布 | 下行接收 |
|---|---|---|---|---|
| 主讲人 / 主播 | 是 | 是 | 音频 + 高清视频，可同时发布多档清晰度 | 接收其他上麦用户的音频和必要视频 |
| 普通连麦用户 | 是 | 是 | 音频 + 视频，清晰度可能低于主讲人 | 接收主讲人高清或中清、其他小窗口低清 |
| 弱网连麦用户 | 是 | 是 | 音频 + 低清视频，或只发音频 | 优先接收音频，视频降级或只拉关键画面 |
| 只语音上麦用户 | 是 | 是 | 只发布音频，不发布视频 | 可只听音频，或按需拉少量视频 |
| 普通观众 / 不上麦用户 | 否 | 否 | 不发布音视频 | 通过 CDN 拉一路混流直播 |
2. 上行发布逻辑
上行不是“所有人都上传音频和视频”，而是按角色和设备状态发布。
| 用户状态 | 上行音频 | 上行视频 | 说明 |
|---|---|---|---|
| 上麦且开麦 | 发布 | 不一定 | 音频通常是连麦的基础流 |
| 上麦且开摄像头 | 发布 | 发布 | 视频可以是单档，也可以是多档清晰度 |
| 上麦但关闭摄像头 | 发布 | 不发布 | 适合语音连麦、弱网、隐私场景 |
| 普通观众 | 不发布 | 不发布 | 不进入 SFU 连麦链路，只看播 |
典型发布模型：
A 主讲人发布：audio_A + video_A_1080p / 360p / 180p
B 连麦用户发布：audio_B + video_B_360p / 180p
C 弱网用户发布：audio_C + video_C_180p
D 只语音用户发布：audio_D，不发布 video_D
普通观众：不发布任何媒体流
3. SFU 的订阅与选择性转发
SFU 的关键不是“全量转发”，而是“按订阅转发”。客户端会告诉 SFU：我现在需要哪些人的音频、哪些人的视频、需要什么清晰度。
例如 4 人连麦 A、B、C、D：
| 订阅者 | 音频订阅 | 视频订阅 |
|---|---|---|
| 用户 A | B、C、D 的音频 | B 360p、C 180p；D 没有视频 |
| 用户 B | A、C、D 的音频 | A 1080p、C 180p |
| 用户 C（弱网） | A、B、D 的音频 | A 360p、B 180p，必要时只保留主讲人 |
| 用户 D（只听不看） | A、B、C 的音频 | 不订阅视频 |
所以理论上 N 人连麦时，每个人最多可以拉 N-1 路流；但实际不会无脑拉满。真实系统会根据页面布局、当前说话人、网络状态、设备性能来决定订阅哪些流。
4. 清晰度处理逻辑
SFU 常见有两种清晰度处理方式：Simulcast 和 SVC。
4.1 Simulcast：发布多档独立视频流
同一个用户同时发布多档清晰度，例如：
video_A_1080p：主画面 / 主讲人高清
video_A_360p：小窗口 / 普通网络
video_A_180p：弱网 / 缩略图
SFU 不需要解码画面，只根据订阅关系转发合适的那一路。
| 场景 | 推荐清晰度 |
|---|---|
| 主讲人、大画面 | 720p / 1080p |
| 小窗口宫格 | 180p / 360p |
| 弱网用户 | 180p，甚至不拉视频 |
| 屏幕外用户 | 不订阅视频 |
4.2 SVC：一个视频流内部分层
SVC 可以理解为一条视频流里包含基础层和增强层：
基础层：低清，保证可看
增强层：中清 / 高清，网络好时叠加
SFU 可以只转发基础层，也可以转发更多增强层。它仍然不需要像 MCU 那样完整解码、混流、重新编码。
5. 下行接收逻辑
下行由“订阅关系”决定，而不是由房间人数简单决定。
| 用户类型 | 下行策略 |
|---|---|
| 主讲人 | 拉其他上麦用户音频，视频只拉需要展示的小窗口 |
| 普通连麦用户 | 主讲人拉高清，其他人拉低清或不拉 |
| 弱网用户 | 音频优先，视频降级；严重弱网时只拉主讲人或不拉视频 |
| 只听用户 | 拉音频，不拉视频 |
| 普通观众 | 不从 SFU 拉多路流，只从 CDN 拉一路混流 |
关键原则：音频通常优先全量转发；视频按需订阅，能不拉就不拉，能低清就不高清。
6. CDN 看播分支
多人连麦和大规模看播要分开处理。
连麦端适合走 SFU：
上麦用户 <-> SFU <-> 上麦用户
普通观众适合走 CDN：
SFU / 混流服务 -> 转码 / 混流 -> CDN -> 普通观众
普通观众不需要连接 SFU，也不需要订阅每个上麦用户的独立音视频流。他们只需要拉一路已经混好的直播流，例如一路包含主播和嘉宾画面的 HLS / FLV / WebRTC-CDN / LL-HLS 等看播流。
好处：
- SFU 只服务实时互动用户，压力可控。
- CDN 承担大规模分发，适合几千、几万甚至更多观众。
- 观众端只拉一路流，带宽和播放器复杂度都低。
- 连麦端保留低延迟互动能力。
7. 推荐实际架构
上麦用户 A/B/C/D
|
| 发布自己的音频 / 视频多档清晰度
v
SFU
|
| 按订阅关系选择性转发
v
其他上麦用户
同时：
SFU 或混流服务
|
| 合成一路直播画面 + 转码
v
CDN
|
v
普通观众
8. 设计结论
WebRTC SFU 架构下，理论上 N 人连麦每个用户最多拉 N-1 路，但实际产品不会这么做。正确做法是：
- 上麦用户只发布自己的媒体流。
- 普通观众不上麦，不进 SFU 多路订阅链路。
- 音频优先保障，通常全量订阅。
- 视频按需订阅，主画面高清，小窗口低清，屏幕外不拉。
- 弱网用户自动降码率，必要时只保留音频。
- 大规模观众统一走 CDN 看播链路。
一句话总结：SFU 负责低延迟互动，CDN 负责大规模观看；SFU 内部靠订阅关系和清晰度选择来控制带宽。
