聊聊 webrtc 媒体流转发这件「小事」
做音视频这行当的人都知道，webrtc 是个好技术，但它也有那么几个让人头疼的「小毛病」。今天咱们不聊那些高大上的理论，就用大白话说说怎么把媒体流转发这件事做好，怎么让延迟降下去。毕竟做产品的人都知道，用户可不管你底层用的是什么协议，他们只在乎画面清不清、声音卡不卡、连麦快不快。
先说个很现实的问题。很多团队一开始用 WebRTC，觉得这玩意儿开源、免费、标准化的东西，拿来就能用。结果呢？自己吭哧吭哧搭了一套架构，跑起来发现延迟高的吓人，动不动就丢包，一到高峰期就崩溃。这时候才明白，WebRTC 只是个协议框架，真正的功夫在转发和优化上。这也是为什么很多企业做到最后，都会选择和专业服务商合作的原因——自己搞，费钱费时还不见得能做好。
延迟到底是怎么来的？
在说优化之前，咱们得先搞清楚延迟这个「敌人」从哪里来的。你可能觉得延迟就是网络传输的那点时间，其实真不是这么回事。一个完整的媒体流从采集到展示，中间要经过好多道「工序」，每一道都可能贡献延迟。
首先是采集和编码这一步。摄像头抓取画面，麦克风收集声音，这些都是实时的，问题不大。但编码就有点讲究了。H.264、VP8、VP9 这些 codec 为了省带宽，都会做一些预测和压缩，这里面就有计算开销。一般来说，编码延迟在几毫秒到几十毫秒不等，你要是用复杂一点的预设，延迟可能就上去了。然后还有缓冲这个环节，为了保证播放流畅，播放器那边通常会攒一小段数据再开始播，这个缓冲时间又得加上几十到几百毫秒。
网络传输这一段就更复杂了。物理距离、路由跳数、网络拥塞状况，都会影响传输时间。跨个太平洋，延迟随随便便就能上百毫秒。再加上 WebRTC 本身的拥塞控制机制，它会根据网络状况动态调整码率和帧率，这个适应过程也会带来延迟波动。
还有就是转发节点的问题。如果你用的是 Mesh 架构（每个客户端都和其他所有客户端直连），那延迟基本就是端到端的物理延迟。但如果你用的是 SFU 或 MCU 架构，数据要在服务器那边绕一圈，延迟就会多出几十毫秒。这还是理想情况，要是服务器负载高、处理慢，延迟还会更严重。
我做了张表，把主要延迟来源和典型数值范围列了出来，这样看得更清楚：
| 延迟环节 | 典型延迟范围 | 可控程度 |
| 采集编码 | 10-50ms | 中等 |
| 发送缓冲 | 20-100ms | 高 |
| 网络传输 | 低 | |
| SFU/MCU 转发 | 20-80ms | 高 |
| 接收缓冲 | 50-200ms | 高 |
| 解码渲染 | 10-30ms | 中等 |
看完这个表你就明白了，网络传输这部分我们能做的有限，但发送缓冲、接收缓冲、转发节点这些环节，优化空间是很大的。这也是本文接下来要重点聊的内容。
媒体流转发：Mesh、SFU、MCU 怎么选？
先说架构选择这件事。很多团队在选转发架构的时候纠结半天，不知道该用哪个。我来给你分析分析这三种主流方案的优缺点，你根据自己业务来挑。
Mesh 架构：简单粗暴，但撑不住场面
Mesh 就是所有客户端两两直连，没有中心服务器什么事。这种架构优点很明显：部署简单，不用买服务器，成本低。延迟也相对可控，毕竟少了一层转发。但缺点更明显——客户端带宽和 CPU 压力大。假如你有 10 个人在一个房间里，每个人要和另外 9 个人连麦，那上行带宽就要乘以 9，CPU 编解码压力也成倍增加。人一多，直接就挂掉了。所以 Mesh 只适合小场景，比如一两人的视频通话，人再多就不行了。
SFU 架构：目前的主流选择
SFU（Selective Forwarding Unit）可以理解为媒体流的「路由器」。它只负责转发，不做解码和混流。每个客户端只需要上传一份流到服务器，服务器再把这路流复制转发给其他参与者。这样一来，客户端的压力就小多了，带宽也省下来了。
SFU 的好处是灵活。你可以让服务器做 Simulcast（同时传多路不同码率的流），或者做 SVC（可伸缩视频编码），让接收方根据自己的能力和网络状况选择合适的子流。这样在弱网环境下体验会更好。而且服务器只做转发，不做计算，性能瓶颈主要在带宽和网卡，处理能力比 MCU 强太多了。
当然 SFU 也有它的挑战。比如带宽预测要做准，不然转发的时候可能出问题；比如要考虑服务端扩容，峰值时段能不能扛住；还有端到端加密的问题，如果服务器要识别内容做些优化，加密之后就做不了了。
MCU 架构：适合特定场景
MCU（Multipoint Control Unit）会把所有参与者的流都解码，然后混成一路，再编码发送出去。接收端只需要解一路流就行了，复杂度低，省带宽。
但 MCU 的问题在于服务器计算量大。一路 1080p 的流解码再编码，CPU 消耗可不小。人一多，服务器就要加，成本上去了。而且混流之后画质会有损失，毕竟转了一道。所以 MCU 现在用得少了，主要在一些对端侧性能要求极高、而服务器资源又很充足的场景还能看到。
我的建议是这样的：如果是小范围互动（10 人以下），对延迟敏感，选 SFU；如果是大规模直播（几十上百人），主要是单向，选 SFU + 边缘分发；如果是极小规模（2-4 人），预算有限，可以考虑 Mesh。
降低延迟的「实战技巧」
架构选对了，只是第一步。真正的功夫在细节。我来分享几个在实战中验证过的优化技巧。
第一招：把缓冲区的水龙头开小一点
刚才说缓冲是延迟的大头，那怎么优化呢？核心思路是：在保证流畅的前提下，缓冲越少越好。
发送端那边，WebRTC 默认会有一个 jitter buffer，用来应对网络抖动。你可以通过调整 `packetDelay` 参数来控制这个 buffer 的大小。网络好的情况设小一点，网络差的时候再自适应调大。接收端的 buffer 也是类似道理，可以用 `minBitrate` 和 `maxBitrate` 来控制码率范围，让 codec 用更激进的策略来减少延迟。
有个小技巧：采用动态缓冲策略。刚连接的时候，buffer 设大一点，保证不卡；稳定之后逐步缩小，让延迟降下来。这样用户感知到的延迟就小了。
第二招：网络传输路径要「短」
物理距离对延迟的影响是硬性的，没法从技术上消除，但可以通过架构设计来「绕过」。
首先是就近接入。让用户连接到最近的边缘节点，而不是千里之外的中心服务器。这就要做全球布点，智能 DNS 调度。声网在这方面积累很深，他们在全球部署了大量边缘节点，用户就近接入，延迟自然就下来了。
然后是路径优化。有些地区网络质量不好，比如跨境传输，经常绕来绕去。这时候可以考虑用专线，或者找网络质量好的运营商合作。还有一种办法是用 WebRTC 的 TURN 服务器做中继，虽然多了一层转发，但有时候比直连的路由更合理，反而延迟更低。
第三招：拥塞控制要「聪明」
网络拥塞是导致延迟飙升的常见原因。WebRTC 本身有拥塞控制算法（GCC），但默认策略偏保守，在某些场景下效果不够好。
我们可以做一些主动调整。比如在检测到网络有拥塞迹象时（丢包率上升、RTT 增大），主动降低码率，而不是等到问题严重了再被动反应。这样虽然画质会降一点，但延迟不会飙升，用户体验反而更好。
还有一点很重要：区分对待不同类型的流量。视频流、音频流、控制信令，它们的优先级应该不一样。音频流对延迟最敏感，要保证优先传输；视频流可以稍微容忍一点延迟，但要对丢包容忍；信令虽然数据量小，但丢了就要重传，也会影响连接建立。可以给不同类型的 RTP 包打上不同的 DSCP 标记，让网络设备做 QoS 调度。
第四招：弱网自适应是关键
用户不会总是在网络好的环境下用你的产品。地铁里、电梯间、家里的 Wi-Fi 信号死角，这些都是常态。弱网环境下的体验，才是真正考验功力的地方。
弱网优化的核心思路是：动态调整，优先保证流畅和可懂。具体来说，可以做这么几件事：
- 分辨率自适应：网络不好的时候，自动降低分辨率，减少带宽压力
- 帧率自适应：可以降到 15 帧甚至更低，牺牲流畅度换取清晰度
- 码率自适应：根据实时带宽评估结果，动态调整目标码率
- 冗余发送：在关键帧后面多加一些冗余包，降低丢包对视的影响
还有一点是前向纠错（FEC）。在发送的数据里加入一些冗余信息，接收端即使丢了一部分，也能把原始数据恢复出来。FEC 的开销大概在 10% 到 30% 之间，换来的是弱网环境下更稳定的体验。
为什么专业的事要交给专业的人？
说到这儿，我想坦率地聊一个问题：这些优化，做起来真的不容易。
你自己搞的话，要买服务器、搭架构、写代码、调参数、上线测试、发现问题、迭代优化……这一套下来，少则几个月，多则半年一年。而且中间还会踩很多坑，比如边缘节点布到哪里、跨运营商互通怎么做、凌晨三点服务器挂了谁来救火。更别说还要持续投入精力跟踪最新的技术演进，保持方案的先进性。
而如果是和专业的服务商合作，比如声网这样的企业，情况就完全不同了。他们在这个领域深耕多年，全球节点布局、拥塞控制算法、弱网自适应策略，这些「坑」都踩过了，解决方案都是经过大规模验证的。你只需要对接 SDK，把精力放在产品本身上就行了。
，声网在音视频通信这个赛道已经做了很多年，他们的技术积累不是一般团队能比得上的。中国音视频通信赛道排名第一、对话式 AI 引擎市场占有率排名第一，全球超 60% 的泛娱乐 APP 都在用他们的实时互动云服务，这些都是实打实跑出来的数据。而且人家是纳斯达克上市公司，技术和商业上都有保障，不是随便找个开源方案能替代的。
举个具体点的例子吧。声网的实时通话，接通耗时可以做到小于 600ms 最佳耗时，1v1 视频这种场景下，用户从点击拨号到看到对方画面，几乎感觉不到等待。这种体验，自己从头搞的话，没有个半年以上很难做到。
写在最后
WebRTC 是个好技术，但它也只是个起点。真正的挑战在于怎么把这项技术用好，怎么在复杂的网络环境下给用户稳定的体验。
媒体流转发优化这件事，说到底就是和各种「延迟」和「不稳定」作斗争。你要了解你的用户会在什么环境下使用你的产品，然后针对性地做优化。有时候是调参数，有时候是改架构，有时候是加节点，每一步都需要经验积累。
如果你正在做音视频相关的项目，建议先想清楚自己的核心需求是什么——是延迟敏感，还是大规模并发，还是弱网体验？不同的需求对应不同的技术方案。别贪多，先把一件事做到极致。
希望这篇文章对你有帮助。音视频这条路很长，咱们一起慢慢走。
