1. 从一次卡顿排查说起：mediasoup 流数据传输到底在传什么
接触 mediasoup 大概是在做第一个多人协作白板项目的时候。当时房间人数一过六个人，画面就开始出现明显的撕裂和延迟累积，日志里 transport 的往返时延一路飙到 400ms 以上。我一开始以为是带宽不够，加了码率上限、换了编码档位，问题依旧。后来把整条链路拆开看，才发现真正卡住的不是网络，而是我对 mediasoup 里“流数据传输”这一层的理解太浅——我只知道它负责把音视频从 A 送到 B，却说不清数据在 Producer、Transport、Consumer 之间到底经历了什么，也不知道 RTP 包在哪个环节被缓存、被转发、被重传。
这篇就围绕 mediasoup 的流数据传输展开，把这条链路从头到尾捋一遍。核心关键词是mediasoup、流数据传输、RTP/RTCP、Transport 传输通道、Producer 与 Consumer 的对接。如果你正在用 mediasoup 做音视频会议、在线教育、直播连麦这类实时场景，或者刚把 demo 跑通、准备往生产环境推，那这篇内容应该能帮你少走一些弯路。我会尽量把每个环节“为什么这么设计”讲清楚，而不是只丢一堆 API 名字给你。
先说结论性的认知：mediasoup 本身不生产媒体，它是一套SFU（选择性转发单元）架构的媒体路由框架。它的核心工作是把上游 Producer 推上来的 RTP 流，按需分发给下游的多个 Consumer。所谓“流数据传输”，本质上是三件事——上行接收、内部路由、下行分发。这三件事分别对应 Transport 的接收、Router 的转发决策、以及 Consumer 的发送。理解了这三段，很多看似玄学的问题（比如为什么某个 Consumer 收不到流、为什么带宽估算不准、为什么切换层级会卡一下）都能找到根因。
2. mediasoup 流数据传输的整体架构与设计取舍
2.1 为什么是 SFU 而不是 Mesh 或 MCU
在动手写代码之前，先想清楚架构选型。实时音视频的拓扑无非三种：Mesh（网状，端到端直连）、MCU（多点控制单元，服务端混流）、SFU（选择性转发）。mediasoup 走的是 SFU 路线，这个选择直接决定了它“流数据传输”的实现方式。
Mesh 的问题是上行带宽随人数线性增长。一个 6 人房间，每个人要往其他 5 个人各推一路流，上行压力是 5 倍。移动端根本扛不住。MCU 的优点是下行只有一路混流，但服务端要做解码、混流、再编码，CPU 开销巨大，而且延迟和画质都会受损，扩展成本高。SFU 折中：每个人只推一路流到服务端，服务端不解码，只做 RTP 包的转发和选择性下发。上行压力恒定，服务端开销主要在带宽和包转发上，CPU 压力小得多。
mediasoup 作为 SFU，它的“流数据传输”因此有一个鲜明特征：服务端不碰媒体内容，只搬运 RTP 包。这意味着它无法做混流、无法做服务端转码（除非你额外接 FFmpeg 之类的模块），但换来的是低延迟和高并发。这个取舍在做方案时一定要想明白——如果你需要服务端录制、需要把多路流合成一路给弱网端，那 mediasoup 原生能力是不够的，得自己补。
2.2 Worker、Router、Transport、Producer、Consumer 五层模型
mediasoup 的对象模型是理解流数据传输的钥匙。从大到小依次是：
- Worker：对应一个独立的 C++ 子进程，是真正干活的媒体引擎。一个 Worker 可以跑多个 Router。生产环境通常按 CPU 核数起多个 Worker，做进程级隔离，一个崩了不影响其他。
- Router：一个房间或一个会话的媒体路由容器。Producer 和 Consumer 都挂在 Router 上，Router 负责把 Producer 的流路由给 Consumer。跨 Router 的流不能直接互通，这是很多人踩的坑。
- Transport：传输通道，分 WebRtcTransport（走 WebRTC，用于浏览器/移动端）和 PlainTransport（走裸 RTP，用于服务端对接，比如接 FFmpeg 或 SIP 网关）。Transport 是 Producer 和 Consumer 的载体，一个 Transport 上可以挂多个 Producer 或 Consumer。
- Producer：一路上行媒体流。比如用户的摄像头、麦克风，各是一个 Producer。
- Consumer：一路下行媒体流。服务端把某个 Producer 的流分发给某个客户端时，就创建一个对应的 Consumer。
数据流向是这样的：客户端采集 → 编码 → 通过 WebRtcTransport 上行 → 服务端收到后创建 Producer → Router 记录这个 Producer → 其他客户端请求订阅 → 服务端在对方的 Transport 上创建 Consumer → RTP 包从 Producer 转发到 Consumer → 下行到客户端解码播放。
这个模型里，Transport 是流数据传输的物理边界。Producer 和 Consumer 必须挂在同一个 Router 下的 Transport 上才能互通。我见过有人把 Producer 建在 Router A 的 Transport 上，Consumer 建在 Router B 的 Transport 上，然后疑惑为什么收不到流——因为跨 Router 根本不路由。
2.3 传输通道的两种形态与选型逻辑
WebRtcTransport 和 PlainTransport 的区别，决定了你的流数据传输走哪条路。
WebRtcTransport 面向浏览器和移动端，内置了 ICE、DTLS、SRTP 这一整套 WebRTC 安全传输机制。它的优点是开箱即用，客户端用标准的 RTCPeerConnection 就能对接。缺点是握手过程相对重，需要交换 ICE candidate、做 DTLS 握手，首次建连有几百毫秒的延迟。
PlainTransport 面向服务端，走裸 RTP，没有加密（或者用 SRTP 但需要自己配密钥）。它的典型用途是：把 mediasoup 的流推给一个录制服务，或者从外部 SIP 网关拉流进来。PlainTransport 建连快、开销小，但需要你自己处理网络层的安全和 NAT 问题。
选型逻辑很简单：客户端一律用 WebRtcTransport，服务端对接一律用 PlainTransport。不要试图让浏览器走 PlainTransport，也不要用 WebRtcTransport 去接 FFmpeg，那是给自己找麻烦。
3. 上行接收：RTP 包是怎么进入 mediasoup 的
3.1 Transport 创建与 ICE/DTLS 握手的关键参数
上行接收的第一步是建 Transport。服务端调router.createWebRtcTransport()，返回的对象里有一堆参数要传给客户端，客户端才能建连。这里面有几个参数直接决定流能不能通：
- listenIps：服务端监听的 IP。这里有个大坑——如果你填的是
127.0.0.1或内网 IP，外网客户端根本连不上。生产环境要填公网 IP，或者用 announcedIp 指定对外暴露的地址。 - enableUdp / enableTcp：是否启用 UDP 和 TCP。UDP 延迟低，优先走 UDP；TCP 作为兜底，应对某些屏蔽 UDP 的网络环境。两个都开是最稳的。
- preferUdp：优先 UDP。一般设 true。
- iceServers：ICE 服务器配置。如果客户端和服务端不在同一网络，需要 STUN/TURN 辅助打洞。纯内网环境可以省，公网环境必须配。
客户端拿到这些参数后，创建 RTCPeerConnection，把服务端的 ICE candidate 加进去，然后做 DTLS 握手。握手成功后，Transport 就处于可用的connected状态。这一步的排查重点是看 ICE 连接状态和 DTLS 状态，如果卡在checking或new，基本是网络或参数问题。
3.2 Producer 的创建与 RTP 参数协商
Transport 通了之后，客户端开始推流。推流前要先transport.produce()，把音视频轨道的 RTP 参数传上去。这里的关键是RTP capabilities 的协商。
mediasoup 要求客户端先拿到 Router 的 RTP capabilities（通过router.rtpCapabilities），然后客户端根据这个能力集，决定用什么编码、什么 payload type、什么 RTX 配置。服务端在produce()时会校验客户端提交的参数是否在能力集范围内，不匹配就报错。
常见的坑是编码不匹配。比如 Router 只开了 VP8 和 H264，客户端硬要推 AV1，那produce()直接失败。另一个坑是 RTX（重传）配置。如果客户端开了 RTX 但服务端没配对应的 apt（关联 payload type），重传包会被丢弃，弱网下画质会明显变差。
produce()成功后返回一个 Producer 对象，它有一个id，这个 id 就是后续创建 Consumer 时的producerId。同时 Producer 会触发producercreated事件，服务端可以在这里做记录，比如把 producerId 和用户 id 关联起来。
3.3 上行带宽估算与码率控制
上行接收阶段，mediasoup 会通过 RTCP 的 REMB 和 Transport-CC 反馈来做带宽估算。这个估算结果会影响客户端的发送码率。如果估算偏低，客户端会降码率，画质变糊；如果估算偏高，网络扛不住会丢包。
这里有个实操经验：不要完全依赖 mediasoup 的自动估算，客户端侧要设一个合理的码率上限。比如 720p 设 1.5~2Mbps，1080p 设 3~4Mbps。设太高，弱网下会疯狂重传；设太低，画质浪费。我一般会在produce()时通过encodings参数指定maxBitrate，给自动估算兜个底。
另外，如果开了 simulcast（大小流），上行会同时推多个分辨率的流，带宽估算会更复杂。simulcast 的每个层级有独立的码率，服务端根据下行需求选择转发哪一层。这个后面讲下行分发时再展开。
4. 内部路由：Router 如何决定把流发给谁
4.1 Producer 与 Consumer 的绑定关系
Router 的核心职责是维护 Producer 和 Consumer 的映射关系。当客户端 A 的 Producer 创建后，客户端 B 想订阅 A 的画面，服务端就要在 B 的 Transport 上创建一个 Consumer，指向 A 的 Producer。
创建 Consumer 的调用是transport.consume()，关键参数是producerId、rtpCapabilities、以及可选的consumableRtpParameters。服务端会校验 B 的 RTP 能力是否支持 A 的流格式，支持才能创建成功。
这里有个容易忽略的点：Consumer 的创建是异步的，而且可能失败。比如 B 的 Transport 还没连上，或者 B 的能力集不支持 A 的编码，consume()会抛错。生产环境一定要做错误处理，并且在前端做重试或降级提示，不能假设订阅一定成功。
4.2 Simulcast 与 SVC：多层流的转发决策
Simulcast 是 mediasoup 流数据传输里最值得讲的部分。客户端上行时推多个分辨率的流（比如 180p、360p、720p），服务端根据每个下行 Consumer 的网络状况，选择转发哪一层。
这个选择逻辑由 mediasoup 内部的Consumer 层选择算法决定。它会参考 Consumer 的带宽估算、丢包率、以及preferredLayers参数。服务端可以通过consumer.setPreferredLayers()手动指定优先层级，比如强制某个 Consumer 走低清。
实操中，simulcast 的配置有几个坑：
- 层级数量不要太多。三层（低中高）足够，四层以上管理复杂且收益递减。
- 每层的分辨率要拉开差距。180p / 360p / 720p 是合理梯度，如果设成 360p / 480p / 720p，中间层意义不大。
- RTX 要每层都配。否则某层丢包时无法重传，体验会断崖式下降。
SVC（可伸缩视频编码）是另一条路，用单个编码流内的分层来实现类似效果。mediasoup 对 VP9 SVC 和 AV1 SVC 有支持，但生态成熟度不如 simulcast，浏览器兼容性也参差。我的建议是：现阶段优先用 simulcast，SVC 等生态再成熟些再上。
4.3 带宽自适应与层级切换的时机
层级切换的时机很关键。切太频繁，画面会不断清晰度跳变，观感差；切太慢，弱网下会持续卡顿。
mediasoup 默认的策略是保守的——带宽下降时先降层级，带宽恢复后延迟一段时间再升。这个延迟是为了避免网络抖动导致的反复切换。你可以通过 Consumer 的setPreferredLayers()和监听layerschange事件来做更精细的控制。
我的经验是：下行带宽低于当前层级码率的 1.2 倍时降层，高于目标层级码率的 1.5 倍且持续 3 秒以上时升层。这个阈值和持续时间可以根据业务调，但核心思路是“降层要快，升层要稳”。
5. 下行分发：Consumer 如何把流送到客户端
5.1 Consumer 的 RTP 参数与客户端对接
Consumer 创建成功后，服务端会返回一组 RTP 参数，客户端用这些参数来接收流。关键字段包括：
- rtpParameters：编码格式、payload type、SSRC、RTX 配置等。
- consumerId：Consumer 的唯一标识。
- producerId：对应的 Producer。
- kind：audio 还是 video。
客户端拿到这些参数后，有两种对接方式：一是用 mediasoup-client 库，直接recvTransport.consume()，库会帮你处理底层细节；二是手动构造 RTCRtpReceiver，自己处理 SDP 协商。前者省事，后者灵活。大多数场景用 mediasoup-client 就够了。
这里有个细节：Consumer 的 RTP 参数里的 SSRC 是服务端重新分配的，不是 Producer 的原始 SSRC。mediasoup 在转发时会做 SSRC 重写，避免多路流之间的 SSRC 冲突。这个重写对客户端是透明的，但如果你在抓包分析，要注意看的是重写后的 SSRC。
5.2 下行拥塞控制与重传机制
下行分发的拥塞控制主要靠 RTCP 反馈。客户端定期发 RTCP Receiver Report 和 Transport-CC 反馈，告诉服务端收到了哪些包、丢了哪些包、延迟多少。服务端根据这些反馈调整发送策略。
重传机制是 NACK。客户端发现丢包后发 NACK，服务端从缓存里找对应的包重发。mediasoup 的 RTP 缓存大小是可配的，默认能覆盖几百毫秒的包。如果 RTT 太高，NACK 重传可能来不及，这时候就要靠 FEC（前向纠错）或者降层来兜底。
实操中，NACK 和 FEC 要配合用。纯 NACK 在高延迟链路下效果差，纯 FEC 会浪费带宽。一般建议：丢包率低于 5% 时靠 NACK，高于 5% 时开 FEC，同时考虑降层。
5.3 多 Consumer 场景下的资源复用
一个 Producer 可能对应多个 Consumer。比如一个老师讲课，50 个学生同时订阅，就是 1 个 Producer 对 50 个 Consumer。mediasoup 在这种情况下会做资源复用——同一路流的 RTP 包只解析一次，然后分发给多个 Consumer，避免重复解析的开销。
但带宽是无法复用的。50 个 Consumer 就是 50 份下行带宽。这是 SFU 的固有成本。如果下行带宽是瓶颈，可以考虑在边缘节点做级联（把流从一个 SFU 转发到另一个 SFU），或者对某些场景改用 MCU 混流。
6. 实操排查：流数据传输中的典型问题与解决
6.1 常见问题速查表
| 现象 | 可能原因 | 排查方向 | 解决思路 |
|---|---|---|---|
| Transport 一直连不上 | listenIps 配了内网 IP | 检查 announcedIp | 改成公网 IP 或正确配置 announcedIp |
| produce 报错 | 编码不在 Router 能力集 | 对比 rtpCapabilities | 统一编码配置，或扩展 Router 能力集 |
| Consumer 创建失败 | 跨 Router 或能力不匹配 | 检查 Router 归属和 RTP 参数 | 确保同 Router，协商能力集 |
| 画面卡顿但带宽充足 | 层级切换频繁 | 看 layerschange 日志 | 调整切换阈值和持续时间 |
| 弱网下画质断崖 | RTX 未配置 | 检查 apt 关联 | 每层都配 RTX |
| 声音正常画面黑 | 视频 Consumer 未创建 | 检查订阅逻辑 | 补上视频轨道的订阅 |
| 延迟持续累积 | 拥塞控制失效 | 看 RTCP 反馈 | 检查 Transport-CC 是否开启 |
6.2 抓包与日志分析实战
排查流数据传输问题，抓包是最直接的手段。服务端可以用 tcpdump 抓 RTP 包，客户端可以用浏览器开发者工具的 WebRTC internals 看统计。
看什么？重点看三个指标：包速率、丢包率、抖动。包速率突然掉零，说明流断了；丢包率持续高于 5%，说明网络有问题；抖动大于 50ms，说明网络不稳定，需要降层或开 FEC。
mediasoup 服务端的日志也很关键。打开 debug 级别日志，能看到 Transport 状态变化、Producer/Consumer 创建、层级切换等事件。我一般会在关键节点打日志，比如producercreated、consumerracreated、layerschange，方便回溯。
6.3 我踩过的三个坑
第一个坑是announcedIp 没配。内网测试一切正常，一上公网就全挂。原因是 listenIps 填了内网地址，客户端拿到的 candidate 是内网 IP，根本连不上。后来在 listenIps 里加了 announcedIp 指向公网地址，问题解决。
第二个坑是simulcast 层级和码率不匹配。低层设了 180p 但码率给了 800kbps，结果低层比高层还清晰，层级切换逻辑完全乱套。后来按分辨率梯度重新分配码率，低层 150kbps、中层 500kbps、高层 1.5Mbps，才正常。
第三个坑是Consumer 没做错误重试。网络抖动导致某个 Consumer 创建失败，前端没处理，用户就一直黑屏。后来加了重试逻辑和降级提示，体验好很多。
7. 生产环境的优化建议与扩展方向
7.1 多 Worker 与多 Router 的部署策略
单 Worker 扛不住高并发时，要起多 Worker。mediasoup 的 Worker 是独立进程，可以充分利用多核 CPU。部署时按 CPU 核数起 Worker，每个 Worker 跑多个 Router。
Router 的划分有两种策略：按房间划分和按用户分组划分。按房间划分简单直接，一个房间一个 Router，房间内所有流互通。按用户分组划分适合超大房间，把用户分成多个组，组内一个 Router，跨组通过级联转发。后者复杂度高，一般房间人数过百才需要考虑。
7.2 边缘级联与就近接入
如果用户分布在不同地域，单点 SFU 会导致远端用户延迟高。这时候要做边缘级联：在多个地域部署 SFU，用户就近接入，流在 SFU 之间转发。
级联的实现方式是：边缘 SFU 把本地的 Producer 通过 PlainTransport 推给中心 SFU，中心 SFU 再分发给其他边缘。这样每个边缘只需要和中心保持一路连接，而不是两两互联。带宽成本可控，延迟也优化了。
7.3 监控指标与告警设置
生产环境必须做监控。核心指标包括：Transport 连接成功率、Producer/Consumer 创建成功率、端到端延迟、丢包率、层级切换频率、Worker CPU 和内存占用。
告警阈值建议：连接成功率低于 95% 告警，端到端延迟高于 300ms 告警，丢包率高于 10% 告警，Worker CPU 高于 80% 告警。这些指标能帮你提前发现问题，而不是等用户投诉。
我个人在实际操作中的体会是，mediasoup 的流数据传输链路虽然环节多，但每一环都有明确的排查入口。关键是不要一上来就怀疑框架，先把 Transport 状态、RTP 参数、RTCP 反馈这三样东西看一遍，八成问题都能定位。剩下两成，多半是网络环境或配置细节的坑，慢慢磨就好。最后再分享一个小技巧：把 mediasoup 的 debug 日志按 Transport id 过滤，排查单个连接的问题时特别高效，比翻全量日志快得多。
