【音视频】WebRTC P2P、SFU 和 MCU 架构

原文链接：https://www.nxrte.com/jishu/webrtc/10152.html

一、架构选择

每个视频会议解决方案的核心都是发送和接收参与者的视频/音频流的架构。例如，如果视频会议中有 N 个参与者，他们每个人都需要看到/听到所有其他 N-1 个参与者的视频/音频。

这可以通过不同的方式实现，但在实践中主要使用三种架构：

• P2P（点对点/网状），
• SFU（选择性转发单元），
• MCU（多点控制单元）。

混合方法也是可能的——根据会议参与者的数量使用不同类型的架构。这更像是一种优化，将在本文末尾进行介绍。

二、P2P（Mesh）

P2P（点对点）有时也称为网状（Mesh）架构。 这是最基本的架构，很容易推理。会议中的每个参与者都是对等点，并通过与每个参与者建立对等连接将他们的视频/音频发送给所有其他对等点。

这是具有 4 个参与者的 P2P（点对点）架构图：

没有中间媒体服务器，因此默认实现隐私（端到端加密）。虽然这听起来不错，但 P2P 架构有一个非常明显的缺点：上传带宽没有得到明智的使用。

• 例如，如果呼叫中有 N 个参与者，则每个参与者需要建立 N-1 个对等连接并发送 N-1 倍的视频/音频，总共 N*(N-1) 个对等连接。
• 尽管如此，许多家庭仍然拥有不对称的互联网连接 – 例如 ADSL（非对称数字用户线），与下载速度相比，上传速度受到严重限制。即使你有很好的上传速度，在许多人共享同一个互联网连接的办公室环境中仍然会出现问题。

实际上，P2P（点对点）架构主要适用于 2 人参加会议的 1-1 通话。在那种情况下，P2P 仍然是最优的，因为 2 个参与者中的每个参与者都只发送一次他们的音频/视频，只发送一次他们的视频/音频。

优点：

• 隐私很容易实现– 默认情况下所有视频/音频流都是 E2EE（端到端加密），因为没有可以监视视频/音频的中间基础设施。
• 复杂性和托管成本也很低，因为没有中间媒体服务器可以托管/实施和关心。

缺点：

• 上传带宽使用不当，即使会议参与者人数很少，也很容易饱和。
• 客户端的 CPU（中央处理单元）使用率会明显更高，**因为浏览器需要对视频进行 N-1 次编码才能将其发送给 N-1 个其他参与者。除非你有一台真正强大的机器，否则性能很容易受到影响。

结论：

• 上述缺点使得 P2P 架构主要针对 1-1 呼叫可靠且不可扩展。实际上，如果会议参与者超过 3 人，您将不会经常看到使用 P2P 架构的视频会议提供商。

三、SFU（选择性转发单元）

这种架构是最近视频会议解决方案的主要选择。有中央SFU 媒体服务器接收发布的流，然后在不修改它们的情况下将它们路由到其他参与者。

虽然显然一些复杂性转移到了服务器端，但它是对P2P的巨大改进，因为它解决了 P2P 遭受的上传带宽和可扩展性问题：

• 联播通常与SFU（选择性转发单元） 一起使用，其中每个参与者将他们的流的多个版本发布到SFU （选择性转发单元） ，每个版本具有不同的质量。然后SFU （选择性转发单元）可以决定将低质量流版本路由到互联网连接较差的参与者。或者仅在参与者在本地最大化流时才提供流的高质量版本。

• 这样可以节省大量的下行链路带宽，并且即使参与者具有普通的互联网连接，也可以在同一个网格中显示许多参与者。
  

从上图可以看出，每个参与者向 SFU 媒体服务器发布一次，并且还接收每个其他参与者的流。

优点：

• 参与者只发布一次– 到 SFU 服务器。这使得 SFU 成为上传带宽友好的架构，与 P2P（网状）不同。
• 比 P2P 架构更具可扩展性。可以使用联播，其中根据可用参与者的 CPU 和带宽路由不同的流版本。
• 灵活的布局——参与者可以决定他们想要接收哪些流、在何处显示它们以及以何种质量显示。

缺点：

• 中间媒体服务器会增加服务器端的成本/复杂性。
• 默认情况下未实现 E2EE（完全隐私），因为中间媒体服务器在转发时可以访问原始流字节。与 P2P 架构相比，这是一个缺点，但可以通过在将流字节发送到SFU（选择性转发单元）媒体服务器之前使用自定义密钥加密流字节来缓解。当然，这意味着接收方需要自定义解密。

结论：

• SFU （选择性转发单元）是当今视频会议中部署最流行的架构。
• SFU 在上传和可扩展性方面比 P2P 更高效。
• 此外，虽然用户仍然需要下载和解码每个其他参与者的流，但可以应用联播技术以允许在平均连接和机器上在网格中显示多达大约 50 个参与者。

三、MCU （多点控制单元）

在MCU（多点控制单元） 架构中，每个参与者仅在他们的流被发送到中央服务器时才发布他们的流。但与SFU不同的是，MCU（多点控制单元） 中央服务器具有混合器的作用——将所有接收到的流合并为一个流。然后所有参与者都使用这个混合流，而不是单独订阅每个其他参与者的流。

优点：

• 每个参与者只订阅一个流——所有其他参与者的组合布局。这在客户端的 CPU 和带宽效率非常高（甚至比SFU更高效），因为浏览器只解码一个流。
• 由于在客户端只消费一个流，因此很容易推理架构并在前端集成/调试它。另一方面，复杂性主要转移到了后端。

缺点：

• 布局通常不灵活——中央服务器确定所有参与者都能看到的固定布局。例如，一个参与者不能重新排序流或最大化另一个参与者的流的质量。
• 由于所有流的混合，与 SFU 相比，服务器端的 CPU 使用率和复杂性要高得多。 房间的缩放主要是垂直的——升级 CPU 以处理越来越多参与者的混合。当然，垂直扩展也有它的缺点，因为要找到越来越强大和可靠的机器既困难又昂贵。
• 与 SFU 相比， 将所有流混合到一个结果流中会引入稍大的延迟，因为 SFU 仅中继流。另外，如果 MCU 布局出现错误，每个人都会受到影响。

结论：

• 虽然如果唯一关心的是客户端资源使用， MCU （多点控制单元） 是最好的架构，但实际上MCU 输给了 SFU，因为将其部署在服务器端的成本至少高出 10 倍。
• 解码/编码和混合比像 SFU 这样的路由/中继流要费力得多。而且由于公司通常无法在服务器端多花至少 10 倍的钱，因此 SFU 是在大多数情况下获胜的合理折衷方案。

四、混合架构

在混合方法中，根据呼叫参与者的数量使用不同的体系结构。P2P 通常用于 1-1 通话，在第三人进入通话后应用程序切换到 SFU。

• 这样一来，一些服务器带宽/资源就可以在 1-1 通话期间节省下来，这可能是一个不可忽略的节省，因为 1-1 通话在人们中非常流行——根据我们的统计和研究，大约 50% 的通话是 1- 1.
• 当然，该百分比可能因产品重点而异——显然，针对大型网络研讨会的产品不会有那么多的一对一通话。

优点：

• 结合多种架构可以根据情况受益于所有架构的优势。 使用 P2P 进行一对一通话可以节省服务器资源，因为没有中间服务器。

缺点：

• 将多个架构组合到同一个应用程序中会增加代码复杂性和维护成本。在 P2P 和其他架构 (SFU/MCU) 之间的平滑过渡在一个正在运行的调用中并不是完全微不足道的。