一文读懂 WebRTC、SFU 与语音编解码器

WebRTC 在浏览器之间传输音频和视频，Opus 等编解码器压缩语音以便在网络上传输，而选择性转发单元（Selective Forwarding Unit，SFU）是一种服务器，在较大规模的通话中把每位参与者的视频转发给其他所有人。这三个部分解释了从麦克风到远端扬声器之间发生的大部分事情。

本指南面向想了解底层机制的开发者和好奇的读者：信令、ICE、STUN 与 TURN、RTP、Opus，以及点对点网状结构与 SFU 之间的取舍。文章最后介绍 Voxal 如何把它们结合起来：语音保持点对点，而摄像头和屏幕共享可以使用 SFU。如果你只想了解概念，请先阅读什么是点对点语音聊天。

1. 什么是 WebRTC？

WebRTC 是一组用于实时音频、视频和数据通信的标准与浏览器 API。

它让应用能够在兼容的设备之间建立媒体连接，而无需开发者从零实现每一种传输和安全机制。

WebRTC 不是单一协议，而是多个组件协同工作。

信令

两台设备在建立媒体连接之前，需要交换有关会话及其连接能力的信息。

这个过程称为信令。应用可以自行选择信令机制；WebRTC 并不规定统一的信令服务器或信令协议。

Voxal 使用信令来协调房间成员和连接的建立。它的信令路径与媒体路径是分开的。

ICE、STUN 与 TURN

设备通常位于路由器、防火墙或网络地址转换（NAT）之后。因此，找到一条可行的连接路径，可能比连接两个公网 IP 地址复杂得多。

WebRTC 使用交互式连接建立（Interactive Connectivity Establishment，ICE）来收集并测试可能的连接路径。

STUN 帮助设备了解自己在公共网络中呈现的地址。
TURN 在无法建立合适的直连时，提供一条中继路径。

TURN 中继转发的是加密的媒体流量。它与 SFU 不同，SFU 会终结媒体连接并有选择地转发媒体流。

直连通常更理想，但中继对于保证连通性可能至关重要。

RTP 与安全媒体传输

实时媒体通常通过实时传输协议（Real-time Transport Protocol，RTP）传输，并配合 RTCP 进行控制和报告。

WebRTC 使用安全 RTP（SRTP）来保护媒体。传输层负责帮助数据包送达，而编解码器决定音频或视频本身如何表示。

这是两种不同的职责：编解码器不负责建立网络连接，网络连接也不决定声音如何压缩。

2. 什么是语音编解码器？

编解码器负责对媒体进行编码和解码。在语音通信中，它的任务是在保持可懂度和可接受音质的同时，高效地表示语音。

如果不压缩，传输原始音频所占用的带宽可能远超语音应用的需要。

编解码器需要在多个因素之间权衡：

音质与语音可懂度。
比特率与带宽占用。
编码和解码的复杂度。
延迟与帧时长。
网络条件变化时的表现。

不存在适用于所有应用的最佳编解码器。音乐流媒体、电话通话、游戏语音和实时群组对话各有不同的优先级。

示意图：麦克风将原始语音波形送入 Opus 编解码芯片，输出低比特率数据流，并配有质量、比特率和延迟的仪表。 — Opus 编解码器把原始语音压缩成低比特率数据流，在音质、带宽占用和延迟之间取得平衡。

Opus 为何被广泛使用

Opus 是一种交互式音频编解码器，专为网络语音电话（VoIP）、视频会议和游戏内语音等应用而设计。

它支持很宽的比特率、采样率和帧时长范围。这种灵活性使它既适合语音，也适合要求更高的音频应用。

根据 WebRTC 音频编解码器要求，Opus 还是 WebRTC 端点必须实现的音频编解码器。

这并不意味着每个 WebRTC 连接始终使用 Opus。实际选用哪种编解码器，取决于参与双方端点协商出的能力。

在 Voxal 中，按照文档所述的架构，浏览器的 WebRTC 音频管线默认使用 Opus。浏览器负责处理大部分底层的编码、传输和解码工作。

对实时语音应用来说，编解码器只是体验的一部分。麦克风质量、音频处理、丢包、网络延迟、抖动缓冲以及设备播放同样重要。

3. 什么是 SFU？

SFU 是 Selective Forwarding Unit 的缩写，即选择性转发单元。

SFU 是一种常用于群组视频通话的媒体服务器。它不要求每位参与者直接向其他每个人各发送一路视频流，而是让每位参与者把媒体发送给 SFU，再由 SFU 把合适的流转发给其他参与者。

设想一个有六个人的房间，每个人都在发送一路摄像头视频流。

在完整的点对点网状结构中，每位参与者可能需要把自己的视频上传给另外五个人。在由服务器转发的拓扑中，每位参与者只需向 SFU 发送一路流，由 SFU 负责分发。

这可以显著减少每位参与者需要维持的独立上行视频流数量。

SFU 究竟做什么？

SFU 通常接收已编码的媒体流，并有选择地转发。根据具体实现和协商的功能，它可以决定向每个接收方发送哪些流或哪些质量层级。

例如，只看小缩略图的参与者，并不需要与全屏显示发言人的参与者相同的视频质量。

SFU 可以帮助应对这些不同的需求，而不必让每个发送方各自向每个接收方单独传输一路流。

不过，SFU 并非没有代价。它会带来基础设施、服务器带宽、运维成本，以及媒体路径上多出的一个组件。

SFU 的隐私模型也与 TURN 中继不同。由于 SFU 会终结媒体传输并有选择地转发媒体，它在技术上可以访问自己收到的媒体。参与者与 SFU 之间的加密本身并不能提供针对该 SFU 的端到端保密性。

4. 点对点网状结构与 SFU

这两种架构解决的是相关但不同的问题。

示意图：对比完整网状结构（每位参与者都与其他所有人相连）与 SFU 转发（每位参与者向中心服务器发送一路流）。 — 在完整网状结构中，每位参与者都要与其他所有人保持连接。使用 SFU 时，每位参与者只向服务器发送一路流，由服务器转发给其他所有人。

点对点网状结构

每位参与者与其他参与者分别建立媒体连接。

优点：

可以使用直接的媒体路径。
无需中心媒体服务器来重新分发媒体。
小型房间无需媒体转发服务也能运行。

取舍：

每个发送方可能需要向其他每位参与者上传一路单独的流。
媒体连接数量随房间规模增长。
上行带宽和连接管理可能成为限制因素。

基于 SFU 的分发

每位参与者把媒体发送给中心转发服务，由它分发给其他参与者。

优点：

在许多群组视频场景中分发更高效。
发送方无需再向每个接收方分别上传副本。
对接收方获得哪些视频流和质量层级有更多控制。

取舍：

需要额外的服务器基础设施，并产生带宽成本。
媒体路径中多了一个中间方。
隐私和信任模型与直接点对点通信不同。

关键在于，不要假定所有类型的媒体都必须使用同一种拓扑。音频和视频的流量模式与需求各不相同。

5. 为什么 Voxal 让语音保持点对点，却可以用 SFU 处理视频

Voxal 把语音音频与摄像头和屏幕共享视频分开处理。

语音音频始终保持点对点，绝不会经过可选的视频 SFU。

这是一个经过深思熟虑的架构决定：语音是核心通信功能，Voxal 不把 SFU 当作集中分发音频的服务。

摄像头和屏幕共享视频则不同。在较大的房间里，完整的点对点网状结构可能要求每位参与者上传多路视频流，随着参与人数增加，这会变得越来越吃力。

因此，当已配置的路由偏好允许，且房间超出网状结构的实际承受范围时，Voxal 可以使用 Cloudflare 的 Realtime SFU 来处理视频和屏幕共享。

路由偏好很重要：

Allow relay for large rooms： 当房间规模超出舒适的点对点视频拓扑时，Voxal 可以使用 SFU。
Prefer direct： Voxal 优先尝试点对点，当网状结构不再适用时，会先询问再允许使用中继。
Direct only： 视频和屏幕共享绝不使用 SFU，即使大房间难以建立全部直连也是如此。

这些设置影响的是视频和屏幕共享，而不是语音音频。

示意图：语音音频在两位参与者之间直接传输，而摄像头视频通过视频 SFU 转发。 — Voxal 把两种媒体分开处理：语音音频始终在对等端之间直接传输，而摄像头和屏幕共享视频在较大的房间里可以通过 SFU 转发。

为什么不把所有内容都走同一台服务器？

因为最合适的拓扑取决于所传输的流量。

语音流通常比摄像头流小得多。让语音经过中心转发服务，会带来另一种基础设施与隐私上的取舍，而对 Voxal 所选的语音架构来说并无必要。

视频的带宽需求更高，随着群组规模扩大，服务器辅助的分发可以带来很大好处。

把两者分开，Voxal 就能保留点对点的语音模型，同时为群组视频提供更具扩展性的选项。

6. 这对隐私意味着什么

网络术语有时被当作能自动保证某种隐私水平来使用。其实并非如此。

点对点音频意味着语音媒体不经过中心媒体服务器，但信令服务器仍可能协调连接并处理相关元数据。

TURN 中继转发加密媒体，但不会对其解码。相比之下，SFU 会终结媒体传输以便有选择地转发流，在技术上可以访问它收到的视频。

这正是 Voxal 所做区分的意义所在：

语音保持点对点，可选择使用加密的 TURN 中继。
在较大的房间里，摄像头和屏幕共享视频可能会使用 SFU，具体取决于路由偏好。
本地的虚拟背景处理发生在发送方的设备上，但仅凭这一点并不意味着每条视频连接都是直连。

了解媒体实际走的路径，比单纯把应用描述为“无服务器”更有价值。

7. 整体回顾

实时通信应用由几个相互独立的层组合而成：

信令协调参与者和连接的建立。
ICE、STUN 与 TURN 帮助建立可行的网络路径。
WebRTC 与安全 RTP 传输承载实时媒体。
Opus 等编解码器高效地表示音频。
网络拓扑决定媒体是在对等端之间直接流动，还是经过转发服务。

Voxal 的设计把这些选择分别应用于语音和视频。结果是一种以语音为先的架构：音频保持点对点，而视频和屏幕共享在较大房间有需要时，可以使用可选的服务器辅助转发。

在设计任何实时通信系统时，这些区别都很重要。目标不是单纯地减少服务器或最大化直连，而是在延迟、带宽、可靠性、可扩展性和隐私之间做出审慎的取舍。

试试 Voxal

Voxal 集成了点对点语音聊天、push-to-talk（按键说话）、免提模式、噪声抑制，以及可选的视频和屏幕共享。

在浏览器中试用 Voxal，或在 Voxal 开源仓库中查看实现。