WebRTC SFU 架构：角色、推拉流与清晰度处理逻辑

一句话理解

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 路，但实际产品不会这么做。正确做法是：

1. 上麦用户只发布自己的媒体流。
2. 普通观众不上麦，不进 SFU 多路订阅链路。
3. 音频优先保障，通常全量订阅。
4. 视频按需订阅，主画面高清，小窗口低清，屏幕外不拉。
5. 弱网用户自动降码率，必要时只保留音频。
6. 大规模观众统一走 CDN 看播链路。

一句话总结：SFU 负责低延迟互动，CDN 负责大规模观看；SFU 内部靠订阅关系和清晰度选择来控制带宽。