聊透 webrtc 媒体流转发的服务器配置

前两天有个朋友问我，说他想自己搭个实时音视频的服务器，看了一堆资料脑子都大了，问我能不能用大白话给他讲讲这里面的门道。尤其是那个"媒体流转发"到底是怎么回事，服务器该怎么配才算靠谱。我想了想，决定把这个问题展开聊聊，争取让小白也能听明白，同时把配置服务器的那些关键点都覆盖到。

在正式开始之前，我想先交代一个背景。说到实时音视频这个领域，就不得不提这个行业里的一些头部玩家。像声网这样的厂商，在这个赛道上深耕了很多年，积累了大量实战经验。他们服务过的开发者遍布全球，涉及社交、教育、游戏、客服等各个领域。这种经过大规模验证的技术方案，对我们理解服务器配置的最佳实践是很有参考价值的。好，废话不多说，我们开始正文。

一、先搞懂什么是媒体流转发

很多人一上来就问服务器配置，但我觉得在动手之前，得先搞清楚我们要解决什么问题。

想象一下这个场景：你和小王在两个不同的城市，你们都想通过视频聊天。这时候最直接的做法是什么？就是你的电脑直接把视频流发给小王，小王的电脑也直接把视频流发给你。这种方式叫做端到端直连，听起来很简单，对吧？

但问题来了。如果只是两个人聊天，直连确实没问题。但如果变成十个人一起视频会议呢？总不能让每个人都给另外九个人发流吧？那带宽开销可就不是闹着玩的了。更麻烦的是，如果这十个人分布在世界各地，网络环境各不相同，有些人的网络可能根本没法直接连上另一个人的网络。

这时候就需要媒体流转发服务器来帮忙了。转发服务器的核心作用用一个词概括就是"中转"——所有参与者的视频流都先发到服务器，服务器再统一把这些流分发给需要的人。这样一来，每个客户端只需要和服务器保持一条连接就行了，大大降低了复杂度和带宽压力。

举个例子会更清楚。假设一场直播有主播和一万个观众，如果没有转发服务器，主播得同时给一万个观众发流，这带宽成本简直不可想象。但有了转发服务器，主播只需要给服务器发一份流，服务器再负责把这份流复制分发到一万个观众那里。这就叫"一对多"的转发场景。

二、转发服务器的几种类型

了解了基本概念后，我们来看看实际部署时可以选择哪些类型的转发服务器。这里主要分为三种架构，每种都有它的适用场景和优缺点。

1. SFU（Selective Forwarding Unit）

这是目前用得最多的一种架构，你可以把它理解成一个"智能分发中心"。服务器会把所有参与者发来的流都收下来，然后根据需要转发给其他人。但它有个特点：服务器不对视频流做任何解码或编码处理，只是单纯地转发。这意味着它能保持原始的视频质量，同时计算开销也比较小。

SFU 特别适合那些参与者较多、但每个人只需要接收部分流的场景。比如视频会议，几个人开会时你可能并不需要同时看到所有人的画面，服务器可以根据你的需求只给你发那几个当前在说话的人的流。这种"选择性转发"正是 SFU 这个名字的由来。

从部署角度看，SFU 服务器的硬件要求相对适中，因为它不做转码这种重活。但它对网络带宽的要求比较高，毕竟所有的媒体流都要经过它转发。

2. MCU（Multipoint Control Unit）

MCU 和 SFU 的思路完全不同。如果说 SFU 是个分发员，那 MCU 就像个"后期剪辑"——它会把所有参与者的视频流都解码，然后在服务器端把它们合成一个统一的画面，再把这个合成后的流发给每个人。

这样做的好处是什么？客户端的处理负担大大降低。想象一下一个手机用户参加视频会议，如果用 SFU，手机可能要同时解码好几路视频流，这对性能要求很高。但如果用 MCU，手机只需要解码一路流就行，体验会流畅很多。

但 MCU 的缺点也很明显。首先是服务器计算量大，视频解码、编码、合成这些都是消耗 CPU 的重活；其次是延迟会比较高，因为多了处理的过程；还有就是画质损失——毕竟服务器对多路视频进行了压缩处理，再发给所有人，画质肯定不如原始流好。

MCU 比较适合那些客户端性能有限、但对延迟要求不那么苛刻的场景。比如传统的电视会议系统，很多用的就是 MCU 架构。

3. Mesh（网状直连）

这种架构最简单，也最"原始"——所有参与者之间直接建立点对点连接，不经过任何服务器转发。

前面我们提到的两人视频聊天就是 Mesh。它的优点是延迟最低，因为中间没有任何中转环节。但缺点也很致命：不支持多人大规模场景，而且很多用户的网络环境根本不允许直连（比如在企业防火墙后面）。

所以 Mesh 一般只适合小规模、理想网络环境下的点对点通信，稍微复杂一点的场景就不太适用了。

三、核心配置参数详解

了解完架构类型，我们来深入到具体的配置参数。这里我会把最重要的几个参数逐一拆解，让你能明白每个参数到底该怎么调。

1. 并发连接数与带宽规划

这是最基础也是最重要的配置。你需要先估算清楚你的系统大概会有多少同时在线的用户，每个用户会消耗多少带宽。

举个实际的例子。假设你要支持一场一百人参与的会议，每个人都开摄像头。假设视频分辨率是 640x480，帧率 15fps，那么每路视频流大概需要 500kbps 到 800kbps 的带宽。一百路就是 50Mbps 到 80Mbps。但这只是上行带宽，作为转发服务器，你还需要考虑下行带宽——服务器要把这些流分发给所有参与者。所以实际需要的带宽可能是这个数字的好几倍。

在规划容量时，建议预留 30% 到 50% 的余量。因为实际使用中总会有突发流量，而且网络状况也会有波动。声网在处理这类大规模并发场景时有丰富经验，他们的标准做法就是在容量规划时留足 buffer。

2. 传输协议的选择

webrtc 默认使用的是基于 UDP 的 SRTP（Secure Real-time Transport Protocol）协议。选择 UDP 而不是 TCP 是有道理的——音视频通话对延迟非常敏感，而 UDP 不会因为丢包而阻塞重传，虽然可能丢失部分数据，但整体延迟更小。

在服务器配置上，你需要确保防火墙打开了 UDP 端口（通常是 50000 到 60000 这个范围）。如果你的服务器部署在云上，还要注意云服务商的安全组配置。

不过凡事都有例外。如果你的应用场景对数据完整性要求很高，比如传输的是重要文件而不是实时音视频，那也可以考虑在 WebRTC 上层协议做些调整，或者干脆不用 WebRTC 传文件。

3. 编解码器配置

编解码器的选择直接影响视频质量和带宽消耗。目前 WebRTC 支持的主流视频编解码器有 VP8、VP9、H.264 和 H.265（HEVC）。音频编解码器则有 Opus、G.711、PCMU、PCMA 等。

视频编解码器的选择建议：

• VP8：兼容性最好，几乎所有浏览器和设备都支持，但压缩效率一般
• VP9：Google 开发的下一代编码器，压缩效率比 VP8 提升约 30%，但设备支持度稍差
• H.264：最广泛使用的视频编码标准，硬件支持非常好，移动端解码省电
• H.265：最新一代标准，压缩效率最高，但专利费用问题让它推广受限

在服务器配置中，你需要明确指定允许使用哪些编解码器，以及它们的优先级排序。一般建议把 H.264 和 VP9 放在前面，因为它们在质量和效率之间取得了较好的平衡。

4. 码率控制策略

码率控制决定了视频流的带宽消耗和画质之间的平衡。这里有几个关键参数需要配置：

目标码率（Target Bitrate）：你想要维持的平均码率。比如 720p 视频通常设置在 1000kbps 到 2000kbps 之间。

最大码率（Max Bitrate）：允许码率波动的上限。当网络状况好时，编码器可以提高码率以获得更好的画质；但不能无限制上涨，需要设置一个上限。

最小码率（Min Bitrate）：保证基本画质的下限。网络不好时，码率可以降低，但降到太低画面就没法看了。

一个好的码率控制策略应该能够根据网络状况动态调整。现在的 WebRTC 实现通常配备了自适应码率算法，会根据实时带宽探测结果来调节码率。

四、网络相关的关键配置

除了服务器软件本身的配置，网络层面的调优也非常重要。很多延迟和卡顿问题，其实都是网络配置不当导致的。

1. NAT 穿透问题

这是一个让无数开发者头疼的问题。简单解释一下：当你电脑在家里的路由器后面时，你的电脑在局域网里的 IP 是 192.168.x.x 这样的内网地址，外网是无法直接访问的。这时候如果两个内网用户要直连 WebRTC，就需要 NAT 穿透技术来帮忙。

主流的 NAT 穿透方案有 STUN 和 TURN。

STUN 服务器的作用是帮助客户端发现自己的公网 IP 和端口。如果两个用户都在普通的家庭网络环境下，STUN 基本就能解决问题，让他们直接连接上。

但如果遇到对称型 NAT 或者企业防火墙，STUN 就无能为力了。这时候需要 TURN 服务器来中转流量。TURN 服务器会把所有媒体流都转发一遍，虽然延迟会增加，但至少能保证连接成功。

在生产环境中，建议同时部署 STUN 和 TURN 服务，并让客户端优先尝试直连（用 STUN），失败后再回落到 TURN 中转。

2. 传输质量监控

想要及时发现和解决问题，监控是必不可少的。以下是几个最关键的监控指标：

指标名称	含义	正常范围
往返延迟（RTT）	数据包从发出去到收到回应的时间	小于 100ms 为优秀，100-200ms 可接受
丢包率	发送的数据包中有多少没能到达	小于 1% 为优秀，1-3% 可接受
抖动（Jitter）	数据包到达时间的波动程度	小于 30ms 为优秀
带宽利用率	实际使用带宽与带宽上限的比率	维持在 60-80% 为宜

这些指标需要实时采集和监控。当发现某个指标异常时，要能快速定位是服务器问题、网络问题，还是某个特定客户端的问题。

五、性能调优的实战技巧

理论知识说得差不多了，最后分享几个在实际部署中很有用的性能调优技巧。

1. 合理使用 CPU 多核

视频编解码和转发都是计算密集型任务。如果你的服务器 CPU 有多个核心，一定要想办法充分利用起来。一个常见的做法是把不同房间或不同类型的任务分配到不同的核心上处理，避免所有任务都挤在一个核上导致性能瓶颈。

现在的服务器动辄就是 8 核、16 核甚至更多，如果配置得当，一台服务器可以同时支撑很多路视频流转发。

2. 内存缓存策略

为了减少网络抖动对视频播放的影响，通常会在接收端设置一个缓冲区。这个缓冲区的大小需要仔细调校——太小了容易出现卡顿，太大了又会增加延迟。

一个经验法则是：缓冲区大小应该能容纳 2 到 3 帧视频的数据。比如 30fps 的视频，每帧间隔约 33ms，缓冲区有个 100ms 左右的数据量就够了。

3. 连接超时与重连机制

网络不稳定是常态，客户端随时可能断开连接。服务器需要能够快速检测到断连（通过心跳机制），并及时释放相关资源。同时，客户端也需要实现平滑的重连逻辑，让用户在网络恢复后能迅速回到通话中。

这里有个细节要注意：重连时最好复用之前已经建立的安全凭证（如果有的话），而不是让用户重新登录一遍。这样能大大缩短重连所需的时间。

4. 地理分布与边缘节点

如果你的用户遍布全球，那就不能把所有流量都集中在一个数据中心。最好是按照用户的地理位置，部署多个边缘转发节点。用户会连接到最近的节点，这样延迟最小，体验最好。

声网在全球有很多节点，覆盖了主要的互联网发达地区。这种全球化的基础设施，对于做出海业务的开发者来说价值很大——用户无论在哪里，都能享受到低延迟的音视频体验。

六、写给想入坑的朋友

好了，聊了这么多，我猜你可能会有点懵——原来配置个音视频服务器有这么多讲究。确实，这个领域水挺深的，涉及网络、编解码、服务器架构、分布式系统等多个方面的知识。

如果你刚开始学习，我的建议是先别急着造轮子，找一个成熟的 SDK 或云服务来用。声网在这方面积累很深，他们的服务经过了无数开发者的实际验证，你可以在上面快速搭建起自己的应用。等你有了足够的经验，再考虑自建服务器的事情也不迟。

当然，如果你确实需要自己搭建，那这篇文章提到的这些配置点希望对你有帮助。记住，服务器配置不是一蹴而就的事情，需要在实践中不断调优。遇到问题不要慌，一点点排查，慢慢就会有感觉了。

最后想说，实时音视频这个领域技术更新很快，WebRTC 本身也在持续演进。今天说的这些内容，过几年可能就有更好的方案了。保持学习的心态，多关注业界的最新动态，这才是最重要的。