WebRTC媒体服务器是 WebRTC 应用中一个可选的组件。也就是说，在大多数常见的使用情况下，你将需要一个。

有不同类型的 WebRTC 服务器。其中之一就是 WebRTC 媒体服务器。你什么时候会需要一个，它到底有什么作用？继续阅读。

WebRTC 中的服务器

WebRTC 应用程序中有很多活动部件。在客户端设备端，你会拥有支持 WebRTC 的 Web 浏览器以及其他类型的客户端，例如其中具有 WebRTC 实现的移动应用程序。

然后是服务器端的组件，有相当多的组件。上面的图示显示了你可能需要的 4 种 WebRTC服务器：

• 应用程序逻辑所在的应用程序服务器。与 WebRTC 直接无关，但仍然存在。
• 用于协调和控制用户如何相互连接的信令服务器，在设备之间传递 WebRTC 信令（WebRTC 没有自己的信令协议）
• 使媒体通过防火墙和 NAT 路由所需的TURN（和 STUN）服务器。
• WebRTC 媒体服务器在需要时在你的基础设施中处理和路由 WebRTC 媒体数据包

下图显示了所有这些 WebRTC 服务器如何连接到客户端设备以及流经它们的数据类型：

有趣的是，WebRTC 基础设施组件中唯一真正可以被看作是可选的部分是 WebRTC 媒体服务器。也就是说，在大多数现实世界的用例中，你将需要媒体服务器。

WebRTC 媒体服务器的作用

在其概念中，WebRTC 是指 “在 “浏览器之间。直到最近，W3C 的好心人认为应该把它改成也能在浏览器中工作的东西。我们一直都知道是这样的😎。

WebRTC 媒体服务器到底做了什么？它通过后端基础设施处理和路由媒体数据包——无论是在云端还是在本地。

比方说，你正在建立一个群组通话服务，你希望有 10 个人能够加入并相互交谈。为简单起见，假设我们想从每个参与者那里获得 1Mbps 的编码视频，并在每个用户的屏幕上显示其他 9 个参与者：

如果没有 WebRTC 媒体服务器，我们将如何构建这样的应用程序？

要做到这一点，我们需要开发一个网状结构：

我们会让客户以 1Mbps 的速率将他们自己的媒体发送给希望在他们的屏幕上显示它们的所有其他参与者。这相当于每个参与者将发送的 9*1Mbps = 9Mbps 的上行数据。每个客户端都从所有其他 9 个参与者接收流，使我们达到 9Mbps 的下行数据。

这可能看起来不多，但确实如此。特别是当通过UDP实时发送时，当我们需要为每个用户分别编码和加密每个流，并确定整个网络的带宽估计时。即使我们把要求从 1Mbps 降低到一个较低的比特率，这仍然是一个难以处理和解决的问题。

当我们将人数增加到 50 或 100 人时，它变得非常困难（不可能？）。更不用说我们今天看到的 1,000 或更多参与者（主动参与者或被动观众）的数字。

进入 WebRTC 媒体服务器

这是 WebRTC 媒体服务器的用武之地。我们将在此处添加它以便能够为我们执行以下任务：

• 减轻客户端上游连接的压力
  • 现在客户端将向服务器发送更少的媒体流
  • 服务器会将收到的媒体分发给其他客户端
• 处理带宽估算
  • 每个客户端负责服务器前面的带宽估算
  • 服务器负责整个“操作”，了解所有客户端的可用带宽和限制

以下是实际情况以及我们使用这些媒体服务器的目的：

👉WebRTC媒体服务器弥补了我们无法单独用客户端解决的架构中的差距

WebRTC 媒体服务器与 TURN 服务器有何不同

在我们继续深入研究不同类型的媒体服务器之前，有一些事情必须要说清楚和讨论：

WebRTC 媒体服务器 != TURN 服务器

我见过人们尝试使用 TURN 服务器来完成媒体服务器的工作。通常是记录数据流之类的事情。

这是行不通的。

TURN服务器通过防火墙和NAT设备路由媒体。他们并不了解通过他们发送的数据。当数据通过 TURN 服务器时，WebRTC的隐私是通过端到端加密来维护的——TURN 服务器不知道加密密钥，所以不能对媒体做任何事情。

WebRTC 媒体服务器是 WebRTC 客户端在服务器组件中的实现。从架构的角度来看，“会话”在 WebRTC 媒体服务器中终止：

WebRTC 媒体服务器对通过它的所有数据都是保密的，并且在它使用的每个 WebRTC 设备前面充当 WebRTC 客户端。这也是为什么它在WebRTC中不是那么好定义，但同时又是那么多功能的原因。

WebRTC 媒体服务器的类型

WebRTC 媒体服务器的这种多功能性意味着存在不同类型的这类服务器。每一个都在不同的架构假设和概念下工作。让我们在这里快速回顾一下。

使用 SFU 路由媒体

最常见和流行的 WebRTC 媒体服务器是 SFU。

SFU 在设备之间路由媒体，当涉及到媒体处理部分时，尽量少做。

SFU 的概念是，它将布局和显示的大部分决策卸载给客户本身，给他们比其他任何替代方案更多的灵活性。同时，它还负责带宽管理和路由逻辑，以最适合它所使用的设备的能力。

为了做到这一点，它使用了带宽估算、联播、SVC 和许多其他技术（如DTX、级联和RED）。

一开始，SFU 被引入并用于群组通话。后来，它们开始以直播和广播组件的形式出现。

将媒体与 MCU 混合

最古老的媒体服务器解决方案可能是 MCU。

MCU 是在 WebRTC 之前几年推出的，当时网络是有限的。电话系统有/有围绕 MCU 的概念建立的语音会议桥接器。视频会议系统需要使用媒体服务器，只是因为视频压缩需要专门的硬件，后来客户端设备需要太多的 CPU。

👉在电话和音频中，你会看到它被称为混音器或音频桥，而不是 MCU。也就是说，它们在技术上仍然是一样的。

MCU 所做的是接收和混合它从各个参与者接收的媒体流，向客户端发送单个媒体流。对于客户来说，MCU 看起来像是 2 个参与者之间的通话——它是客户真正直接与之交互的唯一实体。这意味着只有一个音频和一个视频流进出客户端——无论参与者的数量以及他们如何/何时加入和离开会话。

MCU 从一开始就很少用于 WebRTC。部分原因是简单的规模经济——MCU 的运行成本很高，需要大量的 CPU 能力（编码和解码媒体很昂贵）。使用 SFU 提供相同或相似的服务会更便宜。有些供应商仍然依赖 WebRTC 中的 MCU 进行群组通话，但在大多数情况下，您会发现 MCU 仅提供记录机制——他们最终所做的是获取所有输入并将它们混合成单个流以放置在存储中。

使用网关桥接标准

WebRTC 中使用的另一种媒体服务器是网关。

在某些情况下，内容——呈现的、实时的或其他方式，需要在 WebRTC 会话中共享，或者 WebRTC 会话需要在另一种类型的协议/媒体上共享。为此，可以使用网关来桥接协议。

发生这些情况的两个主要情况可能是：

1. 将本身不支持 WebRTC 的监控摄像头连接到 WebRTC 应用程序
2. 将 WebRTC 会话流式传输到社交网络（想想 Twitch、YouTube Live，……）

混合媒体服务器

还有一个例子是一种混合媒体服务器。一个可能一起进行路由和处理的。例如，一种群组呼叫服务，它还将呼叫记录到单个流中。此类解决方案正变得越来越流行，并且通常部署为不同类型的多个媒体服务器（与上图不同），每个服务器负责服务的不同部分。将它们分开可以更容易地根据每种媒体服务器类型所需的工作负载来开发、维护和扩展它们。

云渲染

这本身可能不是 WebRTC 媒体服务器，但对我来说这属于同一类别。

有时，我们想要的是在云端呈现内容并在浏览器上与用户实时共享。对于云游戏或云应用程序交付（按小时使用的云中的 Photoshop）之类的事情，情况确实如此。在这种情况下，这更像是一个点对点的WebRTC会话，发生在浏览器上的用户和渲染内容的云服务器之间。

我把它看作是一个媒体服务器，因为云渲染组件的开发和扩展的许多方面更类似于你对WebRTC媒体服务器的看法，而不是对浏览器或本地客户端。

Google Meet 使用哪些 WebRTC 媒体服务器？

让我们看一个示例服务——Google Meet。为什么选择 Google Meet？好吧，因为它现在用途广泛，而且如果您想跟踪 WebRTC 中的功能，最好的方法是密切关注 Google Meet 在做什么。

Google Meet 使用什么 WebRTC 媒体服务器？根据它提供的功能，我们可以收集到构成该服务的类型：

• 支持大型团体会议——这是 Google Meet 使用 SFU 服务器来主持和安排会议的地方。每个用户在同一会话期间有不同的布局，可以灵活地控制其查看的内容
• 录制会议– Google Meet 录制显示单个参与者/屏幕共享并混合所有音频流。对于音频，这意味着使用 MCU 服务器，而对于视频，这更类似于切换 SFU 服务器（总是从可用的视频流中挑选出一个视频流，而不是针对“所见即所得”的那种记录）
• 连接到 YouTube 直播– 在这里，他们使用 RTMP 网关实时连接 Google Meet 和 YouTube Live，而不是像在录制时那样将其存储在文件中
• 从普通电话拨号——这需要一个混合网关桥接服务器和一个 MCU 来将音频混合到会议中
• 基于云的噪声抑制——谷歌决定使用服务器在 Google Meet 中实现噪声抑制。这需要 SFU/桥接网关连接到以这种方式处理媒体的服务器
• 基于云的背景去除 ——对于低性能设备，Google Meet 也在服务器中运行背景去除，并且像噪声抑制一样，这需要一个 SFU/桥接网关来实现此功能

WebRTC 中的分类会议服务可能需要不止一种类型的 WebRTC 媒体服务器，可能以混合模式部署在不同的硬件配置中。

什么时候需要 WebRTC 媒体服务器？

正如我们之前看到的，答案很简单——当只使用 WebRTC 客户端做事是不可能的，我们需要一些东西来弥补这个差距。

我们可能缺少：

• 客户端的带宽，所以我们将通过添加WebRTC服务器来缓解这一问题
• CPU、内存或处理能力，委托给云端
• 执行某些机器学习算法，让它们在云服务中运行可能更有意义（由于 CPU、内存、训练数据的可用性、速度、某些 AI 芯片……）
• WebRTC 和其他不使用 WebRTC 的组件之间的桥接，例如连接到电话系统、监控摄像头、社交媒体流服务等
• 当我们需要服务器上的数据时——所以我们记录会话（我们也可以在没有 WebRTC 服务器的情况下执行此操作，但云中仍然会有一个媒体服务器）

在分析 WebRTC 应用程序的需求时，我通常做的是找到这些差距并确定是否需要 WebRTC 媒体服务器（通常是）。为此，我将解决方案视为没有媒体服务器的P2P解决方案。然后根据要求和发现的差距，我将把某些 WebRTC 媒体服务器元素添加到我的 WebRTC 应用程序所需的基础设施中。

E2EE 和 WebRTC 媒体服务器

近年来，我们看到人们对隐私的兴趣越来越大。互联网已经转向加密第一的连接，WebRTC 只提供加密的媒体。这种对隐私的转变开始是对公共互联网上其他恶意行为者的隐私保护，但后来也转向对服务提供商本身的隐私保护。

通过自己无法访问会议内容的服务提供商来运行群组会议服务正变得越来越普遍。

这种能力称为 E2EE – 端到端加密。

当将 WebRTC 媒体服务器引入混合时，这意味着虽然它们仍然是会话的一部分并且正在自行终止 WebRTC 对等连接（=终止加密的 SRTP 流），但它们不应该访问媒体本身。

这只能在 SFU 类型的 WebRTC 媒体服务器中通过使用可插入流来实现。有了它，应用程序逻辑可以在用户之间交换私有加密密钥，并有第二个加密层透明地通过 SFU——使其能够在不了解媒体内容本身的情况下完成数据包路由的工作。

WebRTC 媒体服务器和开源

了解 WebRTC 媒体服务器的另一个重要方面是，大多数在 WebRTC 中使用媒体服务器的人都使用媒体服务器的开源框架。

我已经写了很多关于WebRTC 开源项目的文章——那里有关于市场状态和开源 WebRTC 媒体服务器的详细信息。

需要注意的重要一点是，通常情况下，不为其 WebRTC 媒体服务器使用托管服务的项目通常会选择开源 WebRTC 媒体服务器来使用，而不是从头开始开发自己的服务器。情况并非总是如此，但它很常见。

视频 API、CPaaS 和 WebRTC 媒体服务器

WebRTC 视频 API 和 CPaaS是我广泛涉及的另一个领域。

决定为他们的WebRTC应用使用CPaaS供应商的供应商主要在两种情况中的一种进行：

1. 他们需要将音频呼叫桥接至 PSTN 以连接到常规电话
2. 他们的解决方案中需要一个 WebRTC 媒体服务器（通常是一个 SFU）

这两种情况都需要媒体服务器……

这导致了以下重要的结论：没有一个做 WebRTC 的 CPaaS 供应商不提供一个可管理的 WebRTC 媒体服务器作为其解决方案的一部分——如果有，那么我会质疑它对大多数潜在客户的作用。

本文转载自实时互动网，文章出处《WebRTC媒体服务器是什么？WebRTC媒体服务器作用，类型及开源等》