为什么需要 WebRTC 服务器
-
随着对交互式视频的需求持续增长，Web Real-Time Communications (WebRTC) 协议凭借其超低延迟流的承诺一直在掀起波澜。WebRTC 也因不需要服务器在对等点之间实时流式传输而广为人知。然而，WebRTC 和服务器之间的关系比乍看起来要复杂得多，尤其是当您希望流式传输给更广泛的受众时。
在本文中，我们将介绍不同类型的 WebRTC 服务器以及您何时可能需要它们。特别是，我们将讨论媒体服务器为各种 WebRTC 工作流带来的无数好处 ，以及您可以采取哪些措施来为您的流媒体解决方案利用这些好处。
-
目录
-
我需要 WebRTC 服务器吗？
这完全取决于您要实现的目标。让我们花点时间分析一下 WebRTC 是如果运作的，为何声称不需要服务器。WebRTC 利用三个 JavaScript API 来捕获、编码和传输数据，从而消除了对可能以其他方式实现这些功能的中间服务器的需求。
- GetUserMedia API — 允许用户通过他们自己的网络摄像头或麦克风捕获原始视频数据。
- RTCPeerConnection API — 获取此原始数据并将其编码以进行传输。它还建立初始对等连接，编码数据将通过该连接传输，并负责将媒体数据从一个点传输到另一个点。
- RTCDataChannel API — 在对等点之间传输其他类型的数据，包括文本和任意应用程序数据。
当涉及到基本的点对点连接时，这些 API 可以完成工作。然而，在大多数情况下，它们严重不足。如果您想要传输给更广泛的受众或穿透 NAT 设备，则尤其如此。即使是标准的基于浏览器的点对点连接在技术上也会使用应用服务器，浏览器所依赖的应用服务器也是相同的。
真的，没有任何服务器就无法真正使用 WebRTC。即使您通过局域网 (LAN) 连接进行点对点传输，并且可以访问计算机的 IP 和端口信息，您仍需要某种方式来托管应用程序。因此，现在我们已经让您不再相信 WebRTC 在任何实际意义上都是一种无服务器技术的想法，让我们探讨一下不同的 WebRTC 服务器是什么以及您何时可能需要每个服务器。
-
WebRTC 服务器的类型
使用 WebRTC 时，您可能会遇到四种 主要类型的服务器。在本节中，我们简要概述了每一个、它们的作用以及何时需要它们。
什么是 WebRTC 应用服务器？
我们在上面已经谈到了这一点。应用程序服务器非常简单地托管应用程序。对于 WebRTC，应用程序服务器通常是托管服务的网站。当然，这些在技术上不是您的 WebRTC 服务的一部分，但作为一种基于浏览器的技术，没有它就无法运行。
是否需要 WebRTC 应用服务器？是的。即使您决定将您的 WebRTC 解决方案用于 LAN 设置，您仍然需要某种方式来托管该服务。
什么是 WebRTC 信令服务器？
WebRTC 中的信令是客户端设备建立连接的过程。基本上，这些设备需要先同意相互通信，然后才能发送和接收数据。为了达成协议，他们需要知道如何“找到”对方。
设备向信令服务器发送包含某些识别信息 (也称为互联网连接建立或 ICE 候选者，例如端口和 IP 信息) 的会话描述协议 (SDP)。该服务器将 SDP 连同其他设备一起发送。它还在对等点之间中继 SDP 接受信号。
是否需要 WebRTC 信令服务器？让我们这样说吧：您需要的是在设备之间中继 SDP 信息以建立连接。如果您的 IP 地址和端口信息随时可用，您可以通过任何有意义的方式建立连接，无论是纸质、电话还是信鸽。归根结底，它只是一段文字。然而，这对大多数人来说并不实用，这使得信令服务器对于您的 WebRTC 工作流来说是必不可少的。
什么是 WebRTC NAT 穿透服务器？
听起来应该很简单——远程连接两个或多个对等点。然而，由于网络地址转换 (NAT) 设备，该过程比乍看起来要复杂得多。这些设备阻止客户端设备定位它们自己的互联网协议 (IP) 地址。在发送 SDP 请求之前，计算机必须知道其 IP 地址。这就是 NAT 穿透的用武之地。
WebRTC STUN 服务器
NAT 遍历的第一种方法称为 NAT 会话遍历实用程序 (STUN)。简而言之，客户端设备 ping STUN 服务器，请求连接。该服务器位于公共互联网上，任何试图与之通信的设备都需要一个 IP 地址。因此，当设备对它执行 ping 操作时，它会使用该设备的 IP 地址进行响应。从 STUN 服务器接收到的信息可以用于通过信令服务器发送的 SDP。
WebRTC TURN 服务器
如果你的 NAT 设备特别严格，那么 STUN 可能对你不起作用。这就是 Traversal Using Relays around NAT (TURN) 出现的地方。在这种情况下，您放弃 ICE 候选者和 SDP 协议连接，而只是绕过 NAT 防火墙。TURN 服务器具有公共 IP 地址，使其易于连接。当两个客户端连接时，它们可以使用 TURN 服务器作为中介相互发送媒体。
WebRTC NAT 穿透服务器是必须的吗？您需要能够与另一台设备建立连接才能向其发送媒体。如果您知道自己的 IP 地址，则无需担心这些花哨的解决方法。不幸的是，对于许多人来说，这是一个很大的“如果”。
什么是 WebRTC 媒体服务器？
根据定义， 媒体服务器 存储数字媒体并使其在网络上可用。在点对点 WebRTC 连接的情况下，此服务器位于对等点之间并充当多媒体中间人，从一端接收媒体并将其发送到另一端。通过这样做，它使 转码 和一对多流成为可能。
是否需要 WebRTC 媒体服务器？从技术上讲，不，特别是如果您只是使用 WebRTC 进行一对一连接。然而，媒体服务器带来了无数的好处，使利用众多工作流程成为可能。让我们仔细看看 WebRTC 媒体服务器可以为您做什么。
-
WebRTC 媒体服务器上的亮点
首先，媒体服务器可以是很多不同的东西。从字面上看，任何接收媒体、存储媒体并使其可供其他设备使用的设备或服务在技术上都是媒体服务器。就 WebRTC 而言，媒体服务器通常有助于承担大容量数据流的负载，从而可以将流式传输给更多的观众。这为各种替代 WebRTC 工作流程打开了大门，包括 Simulcast 和可缩放视频编码 (SVC)。
媒体服务器的类型
您的 WebRTC 媒体服务器可能属于以下两类之一： 选择性转发单元 (SFU) 或多会议单元 (MCU)。这些媒体服务器类型中的每一种都具有不同的优势。
多会议单元 (MCU)
MCU 的主要目的是获取从对等设备提供的媒体并将其重新分发为单个流。基本上，这是向更大的群体流式传输的快速解决方案。由于它发出的是标准信号，因此还可以轻松解码并集成到现有系统中。但是，它缺乏 SFU 的灵活性和可扩展性，因为转码为单个流会占用大量 CPU。
选择性转发单元 (SFU)
SFU 是有选择性的。它比 MCU 稍微复杂一些，因为它接收媒体，然后决定将哪些媒体发送给其他方。它与 MCU 的主要区别在于它不会将所有媒体转换为单个流。相反，它根据特定标准从多个选项中进行选择。这方面的一个很好的例子是 WebRTC Simulcast，其中多个版本的流被发送到 SFU，以便根据可用带宽分发到最终用户设备。在更标准的设置中，SFU 接收单独的流并将它们作为单独的流发送给所有其他用户。
媒体服务器支持的工作流程
媒体服务器允许您利用的第一件事是一对多流媒体。从技术上讲，这无需使用媒体服务器即可实现。但是，发送和接收多个流可能会给单个计算机带来压力。媒体服务器在服务器端充当 WebRTC 对等体，承担收集和发送此数据的负载以减轻上述压力。特别是 SFU 服务器还促进了一些旨在提高流质量和可访问性的工作流程。
WebRTC Simulcast
不要与典型的 Simulcast 混淆，其中一个流同时传输到多个平台，WebRTC Simulcast 是一种媒体以几种不同的比特率进行编码并有选择地分发到各种最终用户设备的方法。 在这种情况下，SFU 的工作是根据可用带宽为给定的对等点选择 最佳比特率。这使得在不牺牲流的完整性的情况下，更容易在一系列带宽上流式传输到各种设备。
WebRTC SVC
与 WebRTC Simulcast 类似，可伸缩视频编码 (SVC) 使多种比特率可用于流式传输。然而，SFU 不是以三种不同的比特率接收三个不同的流，而是接收具有多个比特率层的单个流。SFU 根据需要剥离流层，以适应不同最终用户设备的需求。
媒体服务器优势总结
- 减轻媒体发布者/对等设备的压力
- 节约资源
- 启用数据转码
- 支持 Simulcast 和 SVC 等自适应工作流程
- 有时可以添加其他复杂的功能，例如服务器端机器学习
-
WebRTC 媒体服务器和 OddEngine
开始使用 WebRTC 媒体服务器并不一定很复杂。像 OddEngine 这样的流媒体解决方案提供商可以轻松构建满足您需求的基于 WebRTC 的工作流程。您可以将我们的 Odd Streaming Engine 集成到您现有的基础架构中，或者选择我们的 WebRTC 云平台。