做一个基于WebRTC的多人通话练习项目，最折磨人的不是把“两个人连上”，而是把“五个人连上”之后：画面忽好忽坏、有个人一掉线其他人跟着遭殃、新用户死活挤不进来。我断断续续用了个把月的时间，在某个音视频练习项目里把基于mediasoup的SFU多人通话从“勉强能通”做到了“相对稳定”，核心绕不开三件事：优化、监控、断线处理。这篇把我实践下来整理的完整思路和踩坑记录都写出来，希望对正在折腾SFU多人通话的人有点帮助。
1. 选型与整体架构拆解：为什么是SFU，为什么是mediasoup
1.1 三种多人通话架构的取舍
WebRTC本身是点对点的，多人通话要在一个房间内互通，架构上无非三条路。
Mesh最简单：每个参与者都跟房间里的其他人建立连接，5个人就是10条连接。好处是服务端不碰媒体流，写起来最省事，坏处是每个客户端的上行带宽和编解码压力都要扛住所有人的流，移动端基本撑不过三个人。MCU走的是服务端混流路线，所有流都汇到服务器合成一路再分发，客户端最轻松，但服务器的转码、合流压力巨大，成本高，而且延迟容易被拖起来。
SFU属于中间路线：Selective Forwarding Unit，选择性转发单元。服务端不混流，只做转发。发布者上行一路流，订阅者从服务端按需选中下行的流。5个人的房间，服务端需要转发的流是N×(N-1)/2级别的量，但对服务端来说也就是转发，不涉及编解码，压力可控；客户端买的是灵活性和带宽节省。
我的练习项目一开始也想用Mesh试水，后来实测发现在同一个局域网内三路视频都卡，更别提跨网络了。换成SFU之后，从架构上就把“全员互相连接”的瓶颈绕开了。选SFU还有一个隐藏好处：后续如果想做录制、合流、转码，可以挂在SFU外侧以独立服务的方式做，不污染实时通信主链路。
1.2 mediasoup凭什么合适
SFU方案不少，有现成的LiveKit、Janus、ion-sfu，但我最后还是选了mediasoup。原因很实际：
- 底层是Node.js加C++混合，业务逻辑写在Node层，开发效率高，调试也直观。
- 文档完整，API设计贴近WebRTC标准概念，对学习和排查都友好。
- ICE、DTLS、Simulcast这些核心机制都能直接用，不需要自己从底层实现。
- C++写的核心转发层，性能在开源SFU里名列前茅。
- 不绑定任何客户端框架，信令自己做，灵活性最大。
对应地，它也有明显的缺点：不提供现成的房间管理、权限控制、用户业务逻辑，一切都得自己写。很多人拿到mediasoup会卡壳，就是因为它的定位是“媒体引擎”，不是“完整的音视频应用”。但对我来说，这反而是练习的好机会——想要吃透SFU运行机制，就得能控制每一层。
1.3 整体拓扑与模块划分
我用文字描述一下项目最终跑起来的部署形态，不复杂，但分层清晰：
- 服务端：一台云主机跑mediasoup的Node层，给Worker分配的UDP端口范围预留了10000到20000，防火墙只放行这个段。
- 客户端：Web端用浏览器原生WebRTC能力，移动端先跑通WebView内嵌页面，后续再考虑原生端。
- 信令：走WebSocket通道，媒体层与信令层完全分离，互不干扰。
- 存储：不接重量级数据库，内存里维护房间、用户、Transport、Producer、Consumer的映射关系。
- 监控：一个独立的Node服务周期性拉取Worker、房间和连接的统计数据，上报到简单监控面板。
这样分层的好处是，排查断线问题的时候能快速定位：是信令没送达？还是媒体传输断了？还是根本没人发布流？信令日志和媒体统计分开记录，千万别混在一起，否则排查起来就是灾难。
1.4 练习项目的边界设定
我这里要提醒一句：不是所有场景都需要上SFU。如果是2到3个人的练习，Mesh就够了；如果目标是研究多人群聊、模拟真实会议，那SFU是正确的路径。我的项目边界设定是单房间最多8人、同时最多3路视频发布，超出部分强制音频优先。这个设定直接影响了后面所有优化方向，也让监控和断线处理有了明确目标，而不是无限堆功能。
2. mediasoup核心配置与房间模型：从Worker到Consumer逐层拆开
2.1 核心概念先搞透
初次接触mediasoup的人，最容易被一堆名词绕晕。我换个方式解释：
- Router是会议室，它持有这个房间的编解码能力配置，也就是mediaCodecs。
- Transport是进入会议室的门。每个参与者进门前要先给自己修一扇门，mediasoup里就是WebRtcTransport。门上有两把锁：ICE参数和DTLS指纹，用来建立安全的媒体传输通道。
- Producer是发言者的麦克风。某个参与者发布音频或视频后，服务端会生成一个Producer，代表这一路媒体源。
- Consumer是听众的耳机。订阅者想要听/看某个Producer，服务端就创建一个对应该订阅者的Consumer。
最佳实践是：每个peer创建两个Transport，一个专门用于发送本地流，另一个专门用于接收远端流。职责分离之后，排查问题会清楚很多——发送卡了看发送Transport，接收断了看接收Transport，不会互相干扰。
2.2 关键配置参数细节
配置参数是实践里最容易踩坑的地方。我整理几个最关键的：
Worker的rtcMinPort和rtcMaxPort要预留足够大的连续UDP端口范围。5到8人的会议，每个peer至少2个Transport，每个Transport又涉及ICE候选端口，我实测下来给10000个端口才安心。端口范围太小，新用户会进不来，已有用户偶尔断流，原因就是端口耗尽。
Router的mediaCodecs只加实际需要的编码。默认清单里VP8、VP9、H264、H265、opus一大堆，没必要，还会拖慢协商。我的配置只保留audio/opus和video/VP8。真遇到不支持的端再动态加H264，这比一开始全开要好得多。
WebRtcTransport的初始参数要仔细调：
listenIps必须配置成客户端能访问到的地址。我踩过一次配置成127.0.0.1的坑，远端用户全部掉线。initialAvailableOutgoingBitrate设置得太低，首帧出来巨慢；设置得太高，网络一波动就撞拥塞。我的经验值先给1Mbps，再配合动态码率控制。enableUdp必须开，enableTcp作为备胎。很多企业网络会拦UDP，TCP是救命通道。preferUdp优先UDP没错，但千万别把TCP关了。
appData字段要利用起来。我把userId、roomId、peerId全塞进Transport的appData，排查时一眼就能看出这是谁的哪条通道。
2.3 房间与资源映射设计
内存映射表我用三个Map来管理：
rooms：roomId到Room实例的映射。- Room实例内的
peers：peerId到Peer对象的映射，Peer内部持有该用户的Transport和Producer。 - 订阅关系：从Consumer到它所属的Peer，以及它订阅的Producer，维护一个独立的Map。
这里容易忽略的是：一个Peer可能有多个Consumer，一条音频一条视频，还可能是Simulcast的多层流。所以consumer不能直接挂在Producer下面，必须挂在订阅者侧。
用户进入房间的完整流程是：
- 房间不存在则创建Router。
- 为当前用户创建发送Transport和接收Transport。
- 通过信令把Transport的ICE参数和DTLS指纹下发给客户端。
- 客户端connect之后，服务端等待produce事件。
- 收到produce事件后保存Producer，并通知房间内其他订阅者创建对应的Consumer。
2.4 信令协议里的“坑位”
信令没用什么复杂协议，按事件组织：
join-room：带roomId、peerId，服务端返回房间内现有参与者列表。create-transport：服务端创建WebRtcTransport，返回ICE和DTLS参数。connect-transport：客户端回传本地DTLS参数，完成握手。produce：客户端把本地音视频发布上来，服务端保存Producer。consume：服务端根据订阅关系创建Consumer并返回。resume：接收端就绪后，Consumer开始拉流。
最容易出问题的是consume的时机。如果接收端还没准备好就去consume，Consumer会拉不到流，表现为进了房间但看不到别人。我现在改成：produce完成后先创建Consumer但不resume，等服务端收到接收方的“ready”事件再统一resume。这个顺序调整之后，错误率少了一大截。
3. 多人通话的优化实践：从“能通”到“好使”
3.1 编码协商与码率设置
WebRTC的码率是动态协商的，但SFU场景下必须额外注意下行码率。一个关键点：Consumer创建后必须设置preferredBitrate，否则mediasoup会按照Router的默认配置发送码率；多人同时订阅时，服务端出口带宽会被瞬间打满。
我的项目在实际运行中，音频用opus默认，稳定在32kbps左右。视频用VP8，桌面共享场景开启Simulcast，三层经验值是150kbps、500kbps、1.2Mbps。
给个建议：即使只用一个编码器，单路最大码率也不要超过2Mbps。原因很实在：SFU要把你的流同时扇出给N个人，你的上行只有一份，但服务端的出口是N份。设置太高纯属浪费出口带宽，还容易把自己卡死。
3.2 Simulcast的正确打开方式
多人会议最容易出现的问题是：订阅者如果只看最高清晰度，全员带宽爆炸；如果只选最低清晰度，远一点的内容根本看不清。Simulcast就是发布者同时发出多路不同分辨率的流，订阅者按需选层。
mediasoup对Simulcast的支持很完整，但我在练习中发现一个常见误区：produce时没有设置encodings数组。不设置的话，mediasoup会把流当成普通单层流处理，Simulcast根本不生效。
正确的做法是在produce时传参，格式类似：
encodings: [ { maxBitrate: 150000, scalabilityMode: 'S3T3' }, { maxBitrate: 500000, scalabilityMode: 'S3T3' }, { maxBitrate: 1200000, scalabilityMode: 'S3T3' } ]scalabilityMode要参考浏览器和端侧支持来选择，不是随意填的。我实测下来，Chrome系用S3T3比较稳，部分移动端内核只认L1T3，协商失败就要降级到单层。
3.3 带宽自适应与拥塞控制
WebRTC自带拥塞控制，但SFU必须配合。mediasoup里有两种带宽评估机制：
- REMB：接收端估算可用带宽，反馈给发送端。实现简单，但在丢包场景下容易误判。
- Transport-cc：基于传输层的拥塞反馈，更精确，也更现代。
我的项目里优先开启Transport-cc，实测比REMB稳定很多。注意，不是所有客户端都支持Transport-cc，所以代码里要做能力检测：支持的就用Transport-cc，不支持的退回REMB。这正是WebRTC互通里常见的“渐进增强”思路。
3.4 优先保语音的策略
这句话我实践下来必须刻在墙上：视频画质降了用户还能忍，声音断了用户直接走人。所以项目里有一条铁律：音频质量在任何情况下优先于视频。
具体做法是，定期通过Consumer.getStats()获取统计数据，计算每条音频流的packetLossRatio。如果连续3个采样周期超过5%，就主动把同房间内所有人的视频preferredBitrate降到最低档；等音频恢复正常两个周期后，再慢慢把视频码率提回来。
这套逻辑不复杂，但效果极其明显。丢包发生时用户可能会觉得画面模糊，但绝不会听不清别人说话。从用户反馈来看，语音优先策略是整套优化里性价比最高的一项。
关键参数建议对照表：
| 参数 | 位置 | 推荐值 | 作用 |
|---|---|---|---|
| rtcMinPort | Worker | 10000 | 控制UDP端口下限 |
| rtcMaxPort | Worker | 20000 | 控制UDP端口上限 |
| initialAvailableOutgoingBitrate | WebRtcTransport | 1000000 | 尽快出首帧 |
| maxBitrate | Producer encodings | 1200000 | 单路最大码率 |
| preferredBitrate | Consumer | 300000-1200000 | 控制订阅者下行码率 |
4. 监控体系的搭建：别等用户喊卡才去查
4.1 该监控什么
被用户喊“卡”喊了三次之后，我就明白一个道理：没有指标，全靠猜，一定是死路。监控要从四个层面铺开：
- 系统层：Worker进程的CPU和内存占用率，超过阈值就说明承载能力快压满了。
- 网络层：ICE连接状态、RTT往返时延、传输丢包率。这是用户卡顿感最直接的来源。
- 房间层：房间数量、每个房间的Peer数量、Producer和Consumer数量，重点防止资源泄漏（用户退出但对象没正常销毁）。
- 应用层：join时延、首帧时延、断线重连成功率。这四个指标直接反映用户能感知的体验。
4.2 mediasoup stats接口怎么用
mediasoup提供的stats能力足够完善，关键是知道去哪取、取什么。三个入口：
worker.getStats()：全局统计，能看到总字节数、丢包、RTP统计。producer.getStats()：发送端统计，能看比特率、丢包率、RTP信息。consumer.getStats()：接收端统计，字节数、损失包数、bitrate都有。
我的监控脚本每10秒跑一次worker.getStats()和所有活跃Producer/Consumer的getStats()，把关键指标归一化后push到内存数组。为什么不用数据库？因为实时面板看的是最近几分钟的趋势，内存数组足够；真要分析历史数据再落库不迟。
调用stats时有个细节极容易踩坑：media获取时要用{ notruncate: true }参数，否则返回的数据会被截断，丢包和RTT的完整数据根本看不到。
4.3 监控面板与告警规则
面板不用做复杂，前端定时拉一个/metrics接口，展示最近30分钟的CPU、内存、平均RTT、平均丢包率、在线人数曲线就够用。
告警规则比展示更重要。我的阈值经验：
- Worker CPU持续3分钟超过70%：告警，意味着接近扩容线。
- 某Consumer丢包率连续3个采样周期超过10%：告警，大概率网络问题或服务端拥塞。
- ICE状态从connected变成disconnected超过10秒：告警，代表媒体链路断开了。
- 新用户从join到produce可用超过5秒：告警，信令链路可能异常。
记住一个反直觉的经验：丢包率告警阈值千万别设太低。我一开始设了1%，结果网络正常时也频繁误报，后来调高到10%并加“持续3个周期”的条件，告警才真正有效。
4.4 日志里的时间线思维
排查问题最有效的手段，是把所有关键事件按统一时钟打点：user join、transport created、ICE connected、producer created、consumer created、stats采样。
日志格式尽量统一为一行JSON，包含时间戳、事件名、peerId、roomId、关键参数。这样可以用grep按时间切片，快速还原某个用户从进入到掉线的完整轨迹。
我靠这套日志时间线，解决过一个特别诡异的“时断时续”问题。把所有断流事件和信令事件按时间排序后才发现，是某个用户反复触发create-transport，导致端口分配接近上限，其他用户的新连接全部受影响。不看时间线，这个关联几乎不可能定位。
5. 断线问题排查实录：那些最劝退的坑
5.1 断线类型先分个类
音视频断线不能一概而论，我分成三层：
- 信令层断开：WebSocket断了，但WebRTC媒体层可能还活着。
- 媒体层断开：ICE状态变为disconnected或failed，但信令正常。
- 应用层异常：房间或Producer被误删，流被意外关闭。
三层拆分开排查，能省掉90%的时间。我之前习惯一看到“掉线”就去查网络，结果很多次是应用层逻辑错误把Producer关了。
5.2 网络切换导致的永久掉线
典型场景：手机从Wi-Fi切到4G，Wi-Fi下的RTC连接直接失效，新网络收不到原地址的包，画面彻底黑掉。
一开始我的代码只监听ICE状态变化，不做任何处理，用户就一直是黑屏。后来改成两层重连策略：
- 轻量恢复：ICE变为disconnected时先不销毁Transport，等服务端判断RTT和丢包率。如果10秒内没恢复，再触发重建流程。
- 重量恢复：网络切换后，重新创建Transport、重新produce、重新从服务端拉取现有Producer建立Consumer。
关键教训：网络切换后只重连信令是不够的，媒体Transport必须重建。我在代码里把“transport重建”和“consumer重建”拆成两个独立事件流，用事件驱动而不是同步调用，避免一个流程卡死导致整个重连失败。
5.3 ICE状态在connected和disconnected之间来回跳
这个问题最隐蔽，现象是画面偶尔马赛克、声音偶尔断，但从不完全挂。日志里ICE状态在connected和disconnected之间快速切换。
排查下来根因是配置了多个IP候选导致。listenIps里同时配置了内网和公网地址，客户端协商时选了内网IP，但网络路径实际上不走内网，于是ICE不停尝试切换候选，状态就一直抖动。
解决办法是：监听地址只保留客户端真实可访问的地址。宁可少一个候选，也不要提供“看上去可选、实际不通”的候选。这个改动看起来很小，但对稳定性提升非常大。
5.4 UDP端口耗尽导致的连接失败
端口规划在前面提到过，这里说一个真实教训：某次测试会话开到12人，端口范围没控制好，新用户报错“cannot create transport”或“unable to allocate port”。
查看Worker日志能直接看到端口分配失败的原因。解决办法有两个：
- 扩大端口范围。
- 更优雅：限制单房间最大人数，并且通过迁移Transport来动态调整端口资源。
我最后选了扩大端口范围，同时加了房间人数限制。这里有一个实践建议：如果在容器里跑mediasoup，端口范围要配置成环境变量注入，不要写死在配置文件里，否则换环境就是噩梦。
5.5 排查工具与方法论
我完整排查一个断线问题的顺序是：
- 看信令日志，确认事件有没有走到。
- 看stats数据，确认谁在发、谁在收、谁在丢包。
- 需要时用抓包工具看网络层的RTP和ICE候选的有效性。
具体到一次“进入房间后看不到别人”的排查，过程是这样的：
- 信令日志显示produce成功，事件正常走到了。
- 看消费者侧的Consumer.getStats()，发现bitrate为0，包数不涨。
- 抓包发现Consumer对应的RTP流在服务端根本没发出去。
- 查代码发现是Consumer创建时没有执行resume，接收端一直处于暂停状态。
修复就是一行代码的问题，但不按这个顺序排查，可能要在网上搜三天。
5.6 断线重连设计细节
重连不能简单地“重新进房间”。我踩坑后整理的标准流程：
- 客户端检测到ICE failed后，立即上报服务端，服务端把该用户的所有Producer和Consumer先关闭，释放资源。
- 客户端重新走join-room流程，但带上上次的房间号和新生成的peerId。
- 服务端不重建房间，房间里的其他Producer保留，由重连用户重新订阅。
- 完整重连链路：创建transport -> connect -> produce -> 请求所有现有Producer建立Consumer。
重连请求要有退避策略。我设置的是：连续3次失败后，间隔指数退避，从2秒起跳，最多30秒。绝对不能无脑重试，否则服务端会被同时涌来的请求打崩。
5.7 断线问题的深层原因分析
很多断线表面上是用户网络问题，根子却在服务端：
- Worker线程被某个房间的大流量阻塞，导致整个Worker上的RTC包延迟，表现为所有人瞬时卡顿。
- 频繁创建销毁Router，触发GC停顿，RTP包在停顿期间被挤出接收窗口。
解决方式是让不同房间分散到不同的Worker，同时限制单Worker的房间数。numWorkers可以设多个，但不要无脑设大，必须看CPU核数。更关键的是，多Worker模式下信令层也要跟着改：比如按roomId哈希到固定Worker，保证同一个房间的所有媒体操作落在同一个Worker上，否则会出现“Producer在Worker A、Consumer被路由到Worker B”的断线错觉。
注意：多Worker不等于多房间自动负载均衡，需要自己在业务层做路由约定。这个约定是所有后续排查的地基。
结尾：实操体会和一个小技巧
做完这个练习项目，我最真实的感受是：别把它当demo写，要当成一个会随时坏掉的系统来设计。断线、卡顿、资源泄漏，这些全是真实生产环境的常客。用监控和重连机制提前把它们兜住，比事后救火重要得多。
最后分享一个小技巧：任何时候，先确保信令日志和媒体统计的时间戳是同源的。我之前就吃过亏，两套日志各用各的服务器时区，结果同一个断流事件在两个日志里时间差了几十秒，浪费了整整一个下午来做时序对齐。后来统一用字符串格式保存服务端时间戳，再做断线问题的时序分析，顺畅多了。
音视频这块想做好，没有捷径，但也没有想象中那么玄学。把架构选对、参数调对、监控建好、断线想清楚，剩下的就是一轮一轮的真实场景测试。这套路径走完了，SFU基本上也就吃透了。
