一图掌握 WebRTC 通信链路与 SFU 架构：mediasoup 核心模块解析

1. 这张图先解决什么问题

WebRTC 的通信流程、SFU 架构、mediasoup 部署，这三个词经常出现在同一个需求里，但很少有人能把它们串成一张图。我先说结论：WebRTC 从来不是一个 API 能解决的事，它是一条从采集、编码、信令、穿透、传输到解码播放的完整链路；SFU 是让这条链路从一对一走向多人会议的关键架构；mediasoup 则是把 SFU 落到工程里最常见的开源参考实现。这篇文章适合两类人：一是刚接触 RTC 的前端，想搞懂 PeerConnection 之外还有什么；二是架构师在选型时想确认 mediasoup 到底能不能满足业务。如果只是背几个 API，你会觉得都会了，真上线时照样黑屏、卡顿、连不上。

我习惯把这类知识拆成三层：第一层是“一次通话怎样从麦克风走到扬声器”，第二层是“多人场景为什么需要 SFU”，第三层是“mediasoup 内部怎么用 Worker、Router、Transport、Producer、Consumer 把这些流动起来”。标题里那句“一图了解”，本质就是把这三层画进同一张思维导图。很多人拿到别人的图，只看到一个个名词，没看到名词之间的箭头，那等于没看懂。下面我先把最基础的通信链路讲透，再往上叠加 SFU 和 mediasoup。

2. 先把 WebRTC 整条通信链路拆开

2.1 一次通话里到底发生了哪些事

我第一次跑通 WebRTC demo 时，也以为视频通话就是“打开摄像头，addTrack，再调 setRemoteDescription”这么简单。后来发现那只是冰山一角。一次真实通话里，媒体数据要经过下面这些环节：

1. 采集：浏览器通过 getUserMedia 拿到麦克风、摄像头的数据，一般是一路音频和一路视频。
2. 编码：音频用 Opus，视频用 VP8、VP9 或 H.264，编码后变成压缩好的比特流。
3. 打包：把编码后的数据封装成 RTP 包，RTP 才是 WebRTC 媒体传输的最小单位。
4. 信令：双方交换 SDP，告诉对方“我支持什么编码、IP 端口是什么、我要用什么方式加密”。
5. 穿透：通过 ICE 流程找到一条能通的网络路径，必要时借助 STUN 或 TURN 服务器。
6. 传输：RTP 包走 UDP，跑在加密的 DTLS-SRTP 通道里。
7. 解码播放：对端收到 RTP 包后恢复成原始帧，再交给浏览器渲染。

这里最关键的一个反直觉点：WebRTC 的媒体流默认不是走普通 TCP 的。网络差一点没关系，丢包了可以靠丢包补偿和恢复手段来兜底，但延迟不能太高。所以 WebRTC 选择了 UDP，比“必须顺畅、绝不能丢”的传统 Web 请求要复杂得多。

如果用生活场景类比，信令阶段是两个人先在微信群里约好“几点、在哪见面”，媒体流阶段才是见面后的真正对话。微信群里的消息可以延迟、可以重发，但见面之后你说一句对方没听到，你不可能再原封不动重播一遍。这个类比能解释 WebRTC 里很多设计选择，也解释为什么信令服务和媒体服务经常是分开的两套东西。

2.2 信令：SDP 怎么把各自的“能力”摆上桌

WebRTC 标准本身并没有规定信令用什么协议，也没有规定消息长什么样。它只提供了一个规则：双方要交换 SDP，完成 Offer/Answer 协商。SDP 看起来像一段文本配置，里面有音频、视频的 m-line，有编码参数，有 ICE 的认证信息，还有用于 DTLS 握手的指纹。

我摘一小段不完整的 SDP 片段，让你对“换信令时换的到底是什么”有个直观印象：

v=0 o=- 4611738379976 2 IN IP4 127.0.0.1 s=- t=0 0 m=video 51810 UDP/TLS/RTP/SAVPF 96 97 a=rtpmap:96 VP8/90000 a=rtpmap:97 H264/90000 a=ice-ufrag:abc123 a=ice-pwd:def456 a=fingerprint:sha-256 55:2A:AA:...

这段内容的意思是：我这路视频打算在某个端口上用 SRTP 传输，首选 VP8，也接受 H.264，ICE 的临时用户名是 abc123，后面 DTLS 握手的证书指纹是那一串哈希。协商完成之后，两端就知道该往哪里发包、用什么编码解包。

在实际项目里，SDP 一般不会拆开给业务层看，浏览器会自己生成 Offer，远端也有对应的 Answer。你要负责的只是把这段字符串原样通过自己的信令服务转发给对方。信令服务可以是 WebSocket、HTTP 轮询，甚至是直接局域网内发消息，都可以，因为标准不管这一层。

很多人踩坑的点在于：SDP 交换完成后，并不等于媒体路径已经通了。SDP 里只是“约定”，媒体包能不能真正送到，还要靠 ICE 继续探测。如果 ICE 没完成，两端会卡在 connecting 状态，看起来像是没协商成功，其实协商早就完成了。

2.3 穿透与中继：ICE、STUN 和 TURN 的作用

两台设备通常不在同一个局域网，中间隔着一层或多层 NAT。NAT 本身是为了复用公网 IP，但它也带来一个麻烦：外部设备不知道你内部设备的真实 IP 和端口是多少。

STUN 服务器的作用就是“帮你照镜子”。你向它发一个请求，它回你一条消息：你的公网地址是 x.x.x.x：端口 yyyy。之后你把这个地址作为 Candidate 写进 ICE 流程，对端尝试往这个地址发包。这个过程叫打洞，很多家用路由器的 NAT 都能被打通。

但并不是所有网络都能打洞成功。有些企业网络策略严格，或者 NAT 类型是对称型，这时候只靠 STUN 就不够了，需要用 TURN 服务器。TURN 做的事情是：两端都先连接到 TURN，TURN 再把媒体流从一端中继转发到另一端。流量会经过服务器，延迟更高，带宽成本也更大，但它是保底方案。

在画思维导图时，一定要把 ICE、STUN、TURN 放在“网络路径选择”这个分支下，而不是单独扔在线路旁边。ICE 流程会同时收集本地地址、STUN 反射地址和 TURN 中继地址，然后按优先级和连通性不停试探，最终选出一条可用路径。很多人以为只要配了 TURN 就一定走 TURN，其实只有在其他路径都不通时才会用 TURN 兜底。

3. 从 P2P 到 SFU：多人通话为什么必须改架构

3.1 Mesh 并不是没救，而是有上限

一对一场景里，两端直接建立 PeerConnection 就够了。每个人都只向对端推一条流，也只从对端拉一条流，带宽和 CPU 的压力都比较小。可一旦变成多人会议，纯粹的点对点 Mesh 架构就会迅速爆炸。

假设 5 个人开会，每个客户端都要把自己的音频和视频推给另外 4 个人，同时也要从另外 4 个人那拉流。站在一个客户端上看，上行带宽是 4 倍，下行带宽也是 4 倍。如果每个人都有 1Mbps 的视频流，那么一个用户的上行就是 4Mbps。对大多数民用宽带来讲，上传 4Mbps 并不难，但到了 10 人、20 人会议室，单个用户上行会变成 N-1 倍，很快就达到瓶颈。这就是 Mesh 的 O(N²) 问题：总传输量随人数平方增长。

Mesh 不是不能用于小型房间。三五个人临时开会，终端性能也够，Mesh 架构反而最简单，不需要任何媒体服务器。但要支撑真实产品，尤其是有人数上限、质量要求明确的场景，必须换架构。

3.2 MCU 的重活与成本

比 Mesh 更传统的方案是 MCU，也就是多点多控制单元。MCU 会接收所有参会者的音视频流，在服务器端统一解码、合成，最后生成一路或几路混合画面，再分别发给每个人。终端只需要拉一路流，压力非常小。

这个方法逻辑上很直观，但工程代价很高。服务器要做的事情不是转发，而是把多路视频解码出来，重新布局，再编码成一路新的视频流。解码加编码会严重消耗 CPU 和 GPU，而且每次分辨率、码率变化都可能需要重新协商。更重要的是，MCU 会改变媒体流的语义，终端拿到的画面是服务器重新合成的，不是原始流，很多针对原始流的处理和分析都无法直接做。

MCU 适合传统视频会议终端，因为终端能力弱，网络也受控。但在 WebRTC 场景里，终端本来就是浏览器，网络又非常动态，MCU 实在太“重”了，不够灵活。

3.3 SFU 的取舍：转发，但只转发“有人要的那份”

SFU 的完整名字是 Selective Forwarding Unit，选择性转发单元。它站在 Mesh 和 MCU 之间：不混合媒体，只对媒体流做转发，但转发的对象和档位可以由接收方动态选择。

举个例子，某个发言者推流时同时推了三档清晰度：720P、360P、180P。SFU 不会把这三档全发给房间里所有人，而是根据每个接收者的需要选择其中一档转发。弱网用户可能只收到 180P，投屏用户可能请求 720P。这就是“选择性转发”的核心：它不是无脑复制，而是有选择地复制。

相比 Mesh，SFU 把终端的上行压力从 O(N) 降到了 O(1)，因为每个终端只需要向服务器推一路流；相比 MCU，它又不需要解码和重新编码，服务器 CPU 消耗小得多，延迟也更低。因此现在主流 RTC 服务基本都是 SFU 架构，部署形态从单机到集群都有。

用一个表格对比这三种架构会更直观：

这张表就是“为什么选 SFU”的核心理由。很多人讨论时只在“转发”和“混合”两个词上打转，其实关键变量是：媒体流是谁控制的、服务器要不要碰真实内容、终端能不能按需调整。

4. mediasoup：把 SFU 概念变成工程实体的核心模块

4.1 mediasoup 不是什么：先划清边界

先纠正一个容易混淆的点：项目官方名字是小写 mediasoup，不是 MediaSoup。标题里写成 MediaSoup 也不影响搜到它，但技术文档里最好按官方写法来。从定位上看，mediasoup 是一个 SFU 库，不是一个完整的会议室系统。

它不会替你管理用户登录、房间人数、录制、鉴权，也不负责信令。它真正负责的是：接收一端推上来的 RTP 流，把它转发给其他端；决定按什么码率、什么空间层转发；在 WebRTC Transport、Plain Transport、Pipe Transport 之间搬运媒体数据。业务层还需要自己实现 WebSocket 信令、房间状态、权限控制等。

换句话说，medisoup 是“媒体引擎”，不是“业务平台”。它用 Node.js 暴露管理接口，但真正跑媒体处理的是底层 C++ 编写的 worker 进程。Node 进程只做控制，不碰媒体数据，这样设计是为了把 CPU 密集的数据转发任务从 JavaScript 主线程里剥离出去，保证性能。

4.2 Worker、Router、Transport、Producer、Consumer 到底各管什么

用 mediasoup 开发时，最先看到的几个类就是 Worker、Router、Transport、Producer、Consumer。不理解它们的关系，代码基本写不下去。把它们套到“人与人开会”的场景里会好记很多。

Worker 是最顶层的概念，它是一个独立的 C++ 子进程。生产环境通常按 CPU 核心数创建多个 Worker，每个 Worker 可以承载多个 Router。Router 是媒体路由单元，一个会议室一般对应一个 Router。它内部维护了编码器能力列表，比如这个房间允许用哪些音频和视频编码，这些能力在创建 Router 时就要确定。

Transport 是网络传输通道，一个 PeerConnection 对应一个 WebRtcTransport。它包含 ICE 参数、DTLS 参数等。Producer 是上行流，也就是某个用户往服务器推的声音或画面；Consumer 是下行流，也就是某个接收方从服务器拉到的流。

可以用一张表理清：

最常见的错位理解是：把 Router 当成一个房间，于是一个房间一个 Router，逻辑上没错，但还要记住 Router 本身不保存用户状态。房间里的用户是谁，是业务层的数据；Router 只关心流进来之后怎么路由出去。

4.3 一段最简接口骨架

下面这段代码不是可以直接跑的生产代码，而是核心调用骨架。它展示了 mediasoup 服务端最重要的几个步骤：创建 Worker、创建 Router、创建 WebRtcTransport、接收 Producer、下发 Consumer。

const mediasoup = require('mediasoup'); async function start() { const worker = await mediasoup.createWorker(); const router = await worker.createRouter({ mediaCodecs: [ { kind: 'audio', mimeType: 'audio/opus', clockRate: 48000 }, { kind: 'video', mimeType: 'video/VP8', clockRate: 90000 }, ], }); // 信令流程中，收到客户端“准备推流/拉流”的请求后创建 Transport const transport = await router.createWebRtcTransport({ listenIps: [{ ip: '0.0.0.0', announcedIp: '公网IP' }], enableTcp: true, preferUdp: true, }); // transport.iceParameters、transport.dtlsParameters 要返回给客户端 // 客户端完成 DTLS 连接后，服务端再调用： await transport.connect({ dtlsParameters: clientDtlsParameters }); // 客户端开始推流时： const producer = await transport.produce({ kind: 'video', rtpParameters: clientRtpParameters, }); // 其他参会者要观看时： const consumer = await transport.consume({ producerId: producer.id, rtpParameters: negotiatedRtpParameters, }); }

这里最容易被忽略的是announcedIp。如果服务器在内网，外网客户端看到的 Candidate 必须是对外的公网地址。只填ip: '0.0.0.0'，ICE Candidate 里会带上一个内网地址，浏览器尝试连接时直接失败，表现出来就是双方connected不上。这一类问题不是代码逻辑错，而是地址通告配置错。

5. 一图到底怎么画：合并成可沟通的 WebRTC + SFU 思维导图

5.1 顶层树干：终端、信令、媒体服务三层

如果你要画一张“一图了解 WebRTC 通信流程 + SFU + mediasoup”的思维导图，我的建议是根节点不要写 mediasoup，也不要写 WebRTC，而是写“从一端到另一端的媒体流”。根节点定了，主干才会清楚。

主干可以分成三层：终端侧、信令服务、媒体服务。终端侧放采集、编码、PeerConnection、ICE Candidate 收集；信令服务放 SDP 交换、房间管理、业务协议；媒体服务放 mediasoup 的 Worker、Router、Transport、Producer、Consumer。把这层画完，已经覆盖标题里 80% 的内容。

下面是我比较喜欢用的文字版骨架：

WebRTC + SFU 总览 ├─ 终端侧 │ ├─ 采集和编码 │ ├─ PeerConnection 状态 │ ├─ SDP Offer/Answer │ └─ ICE Candidate 收集 ├─ 信令服务 │ ├─ 连接管理 │ ├─ 房间与权限 │ └─ 媒体协商参数交换 └─ 媒体服务 SFU ├─ mediasoup Worker ├─ Router 与编解码能力 ├─ Transport 网络通道 ├─ Producer 上行流 └─ Consumer 下行流

这张图的价值不在于列出所有名词，而在于展示箭头。比如 SDP 从终端到信令服务，再从信令服务到另一端，最终回到 PeerConnection；ICE Candidate 收集后也要通过信令服务交换。箭头方向一旦画错，后面排查问题就会混乱。

5.2 底层细节：生产者和消费者的映射关系

再往下展开一层，你会看到一张更细的映射关系图。一个用户进入房间后，会产生一个 WebRtcTransport。这个 Transport 上可以挂一个或多个 Producer，比如音频 Producer 和视频 Producer。房间里的其他用户，各自通过自己的 Consumer 去消费这些 Producer。

这个关系很像订阅发布模型：Producer 是发布者，Consumer 是订阅者，SFU 就是消息中间件。只不过消息的内容是实时媒体流，发布者不会等订阅者确认，订阅者也可以随时暂停、恢复或改变订阅路数。在思维导图里，我建议给 Producer 和 Consumer 分别画成两个分支，它们的共同父节点是 Transport，而不是 Router。

从业务代码上看，普通参会者通常扮演双重身份：对外是 Producer，对内是 Consumer。画图时最好用两个不同的颜色区分“上行”和“下行”，否则很容易在房间人数多的时候绕晕。

6. 常见问题与排查技巧实录

6.1 屏幕全黑但 IceConnectionState 正常

这是 RTC 开发里最经典的问题：两边都显示已连接，但视频画面全黑，或者音频只有沉默。ICE 状态正常只能说明网络路径已经打通，DTLS 握手也完成了，不代表 RTP 媒体包一定能被正确解码。

优先检查三处：一是 Producer 和 Router 的编码能力是否匹配，比如浏览器推的是 H.264，Router 创建时只声明了 VP8，Consumer 协商出来可能没有可用的编解码；二是接收端拿到的 RTP 参数里 Payload Type 是否一致，很多黑屏问题就是 Payload Type 错位；三是是否一直等关键帧。如果发送端没有及时给出关键帧，接收端拿到的一堆参考帧无法解码，画面就会一直是黑的。

排查时可以看服务端统计里的字节数是否在增长。如果 RTP 包一直在收，但画面还是黑，问题通常不在网络，而在编码协商或关键帧。快速验证方法是用另一个设备同时观看同一路流，如果别人能看到画面，那就是本地解码链路的问题。

6.2 多人房间突然卡顿：Simulcast 没开

SFU 解决了终端上行压力，但如果你只推一路固定高清流，弱网用户会非常痛苦。没有 Simulcast 或 SVC 时，SFU 能做的只是无脑转发，无法按接收端能力平滑降级。你会发现部分参会者卡成 PPT，而服务器 CPU 可能并不高。

开启 Simulcast 后，发送端会同时往服务器推多档视频流，比如 720P、360P、180P。服务器可以根据接收端的网络状况选择转发哪一档；弱网用户可以改收 180P，带宽充足时可以切回 720P。对于 WebRTC 这种实时性要求极高的场景，Simulcast 几乎不是“优化”，而是必需品。排查多人卡顿时，先看 Producer 上到底有没有多档编码，再看 Consumer 是否有 setPreferredLayers 相关逻辑。

6.3 服务器内存和 CPU 不高，但端口不够用

mediasoup 的每个 WebRtcTransport 都会占用 UDP 端口，默认会从配置的 RTC 端口范围内分配。如果防火墙没有放开这个端口范围，或者范围太小，会议人数一多，新用户就无法建立媒体连接。这属于“系统没问题，但没人能开会”的诡异状态。

解决方法是给端口范围设置一个足够大的连续区间，并在防火墙和安全组里放通。常见配置是 40000 到 49999，配合 Worker 复用机制，基本能支撑一个中规模单机服务。如果有人数增长预期，还要考虑把范围扩大或者切换成多机集群。端口不够用的时候，最直接的观察现象是客户端一直 connecting，服务端日志出现端口分配失败。

6.4 Worker 创建失败或 Router 创建失败

这类问题通常在初次部署时出现，表现为 mediasoup 模块加载正常，但调用 createWorker 时抛错。很多时候是服务器资源限制太紧，比如进程最大文件描述符不够，worker 子进程启动不了；也有可能是库文件兼容性问题，或工作目录没有写权限。

排查思路很简单：先看 mediasoup 的详细日志，它一般会告诉你 worker 进程为什么退出。再检查ulimit -n的数值和临时目录空间。别急着换版本或重写逻辑，基础环境不过关的话，代码怎么调都没有用。

为了给你一张速查表，我整理几个最常见的现象和优先排查项：

7. 把这套图落到真实项目时，我先做的事

我第一次用 mediasoup 搭模拟项目时，没有先写房间逻辑，而是先画了两条最基本的链路：一条是推流链，一条是拉流链。推流链上标注“采集 -> 编码 -> Produce -> Producer”，拉流链上标注“Subscribe -> Consumer -> 解码 -> 播放”。等这两条链都通，再去接房间管理和权限控制，后面基本不会乱。

我还有一个个人习惯：排查问题时不直接看具体报错代码，而是先回到思维导图，看问题发生在哪个箭头上。箭头越多，问题越可能在中间层，而不是端点。比如画面黑，先分清楚是采集端的问题、传输端的问题，还是接收端解码的问题。大多数 RTC 项目真正复杂的不是 mediasoup API，而是你能否快速定位“流在哪一段断了”。把这张图画清楚，排查速度会比别人快很多。