WebRTC 终极指南

  什么是 WebRTC？

Web 实时通信 (WebRTC) 既是一个开源项目，也是一个规范，它支持实时媒体通信，如语音、视频和数据在浏览器和设备之间的本地传输。这使用户无需复杂的插件或额外的硬件就可以在他们的主要 Web 浏览器中进行通信。

WebRTC 项目于 2011 年 5 月由 Google 首次宣布，作为开发一套通用协议的一种手段，用于在浏览器、移动平台和物联网设备中启用高质量的 RTC 应用程序。当时，Flash 和插件是提供实时通信的唯一方法。两年后，经过大量工作，Chrome 和 Firefox 之间建立了第一个跨浏览器视频通话。随着越来越多的组织增加对规范的支持，开发者社区对 WebRTC 的支持也随之飙升。今天，WebRTC 在 Chrome、Firefox、Safari、Edge、Android 和 iOS 中本地（不同程度地）可用，并且是一种广受欢迎的视频通话工具。

 

 

  WebRTC API

WebRTC API 有三个主要组件，每个组件在 WebRTC 规范中都扮演着独特的角色：

媒体流（GetUserMedia）：

MediaStream API 提供了一种使用 JavaScript 访问设备摄像头和麦克风的方法。它控制多媒体流数据的消费位置，并提供对产生媒体的设备的一些控制。它还公开有关能够捕获和呈现媒体的设备的信息。

RTCPeer连接：

对等连接是 WebRTC 标准的核心。它为参与者提供了一种与他们的对等方建立直接连接的方法，而无需中间服务器（除了信令）。每个参与者获取从媒体流 API 获取的媒体并将其插入对等连接以创建音频或视频源。PeerConnection API 在幕后进行了大量工作——它处理 SDP 协商、编解码器实现、NAT 遍历、数据包丢失、带宽管理和媒体传输。

RTC 数据通道：

RTCDataChannel  API 被设置为允许任何类型的数据（媒体或其他数据）直接在对等方之间进行双向数据传输。它旨在模仿 WebSocket API；然而，数据通道不依赖于 TCP 连接（可靠但延迟高且容易出现瓶颈），而是使用基于 UDP 的流，并具有流控制传输协议 (SCTP) 协议的可配置性。这种设计实现了两全其美：像 TCP 一样可靠交付，但像 UDP 一样减少了网络拥塞。

 

  建立连接

在开始点对点视频通话之前，需要在两个客户端之间建立连接。这是通过信令完成的。信令不属于 WebRTC 规范的范围，但它是建立音频/视频连接的重要第一步。

信令

信令允许两个端点（发送者、接收者或两者）交换元数据以协调通信并建立呼叫。例如，在两个端点可以开始视频通话之前，一方必须呼叫另一方并且被叫方必须响应。此呼叫和响应消息流（也称为提供-应答消息流）包含有关将要发生的流式传输的关键细节（例如流的数量和类型、媒体将如何编码等），并且通常使用会话描述协议 (SDP) 格式化。SDP 是许多现实世界系统使用的标准格式，包括 VoIP 和 WebRTC。

需要这样做有两个原因：

1. 通常，对等体不知道彼此的能力。
2. 通常，对等体不知道彼此的网络地址。

NAT 遍历 - ICE、TURN 和 STUN

一旦流连接的初始信令已经发生，两个端点需要开始 NAT（网络地址转换）遍历过程。 当 NAT 将公共地址分配给专用网络内的计算机时，可能会导致设置实时视频连接的困难。NAT Traversal 是一种解决与 IP 地址转换相关的问题的方法。

在支持 WebRTC 的视频通话中，除非两个端点在同一个本地网络上，否则两者之间会有一个或多个中间网络设备（路由器/网关）。WebRTC 中使用了三个关键规范来克服这些障碍：

• 交互式连接建立 (ICE) – ICE 用于找到两台计算机相互通信的所有方式。它的两个主要作用是收集候选人和检查连通性。ICE 保证如果有两个客户端通信的路径，它会找到它并使用两种协议确保它是最有效的：STUN 和 TURN。
• NAT 会话遍历实用程序 (STUN) - STUN 代表 NAT 会话遍历实用程序，是一种轻量级且简单的 NAT 遍历方法。 STUN 允许 WebRTC 客户端通过向 STUN 服务器发出请求来找到自己的公共 IP 地址。
• 使用围绕 NAT 的中继进行遍历 (TURN) –  TURN 服务器通过帮助端点了解其本地网络上的路由器以及为无法直接连接的端点之一盲目中继数据来协助 NAT 遍历防火墙限制。

编解码器

在通过对等连接发送媒体之前，必须对其进行压缩。原始音频和视频太大，无法在我们当前的互联网基础设施中有效发送。同样，通过对等连接接收媒体后，必须对其进行解压缩。媒体编解码器（编码器-解码器）正是这样做的。

WebRTC 规定了三个音频编解码器和两个视频编解码器：

1. 音频 – PCMU (G.711μ) 以 8,000Hz 运行，具有单通道（单声道）。
2. 音频 – PCMA (G.711a) 以 8,000Hz 运行，具有单通道（单声道）。
3. 音频 – Opus 以 48,000Hz 运行，带有两个通道（立体声）。
4. 视频 - VP8。
5. 视频 – 使用受限基线配置文件级别 1.2 的 H.264/AVC。

未来的 VP9 和 H.265 等未来媒体编解码器可能会添加到 WebRTC 标准中，但目前它们不是强制性的。LiveSwitch 的专业服务团队等 RTC 专家通常能够添加额外的自定义和未来编解码器支持，以满足任何客户的要求。

 

  WebRTC拓扑

对等（网状）拓扑是 WebRTC 规范中涵盖的唯一连接类型。但是，在许多用例中，网状拓扑是不够的。基于服务器的拓扑可以帮助解决这些缺点，并且经常在 WebRTC 世界中用于传输媒体。任何给定应用程序的最佳拓扑很大程度上取决于预期的用例，因为每个用例都有其独特的一组优点和缺点。

对等 (P2P) 架构

优点

• 最低的运营成本，非常适合简单的用例。
• 对等点直接打开彼此的连接。
• 视频单独发送给每个对等点。
• 服务器只涉及信令和 TURN/TURNS。

缺点

• 随着会议规模的增长，CPU 密集型。
• 如果没有中央服务器，录制是很困难的。
• 每个参与者使用更多的网络带宽。

 

在对等或网状拓扑中，会话中的每个参与者直接连接到所有其他参与者，而无需使用服务器。这种类型的连接非常适合小型视频会议，因为它成本最低且易于设置。然而，当会议变得更大时，保持所有参与者之间的直接连接变得不可持续，因为它可能变得过于占用 CPU。由于对等点之间的连接是直接的，因此网状拓扑也不适用于记录。

由于这些原因，网状拓扑最适合连接两到三个参与者的简单应用程序，其中低延迟很重要并且不需要记录。

潜在用例的示例包括：

• 医生/患者视频咨询
• 1对1客户服务

选择性转发 (SFU) 架构

优点

• 每个参与者都将他们的流发送到服务器（上游）。
• 每个对等点都可以选择打开下游连接来获取您的视频。
• 最受欢迎的连接类型：允许较旧的设备和互联网连接较差的农村参与者积极参与。

缺点

• 需要额外的服务器 CPU 功率才能将音频/视频混合成单个流。

 

In a selective forwarding topology, each participant in a session connects to a server that acts as a selective forwarding unit (SFU). 每个参与者将他们的加密视频流上传到服务器一次，然后服务器将这些流转发给其他每个参与者。这减少了延迟，还允许转码、记录和其他服务器端集成，例如 SIP，这在对等连接中会更加困难。

SFU 拓扑确实有限制。虽然拥有单个上游连接使其比网状拓扑更高效，但拥有多个下游连接意味着一旦会话中有一定数量的参与者处于活动状态，每个客户端最终都会耗尽资源。

由于这些原因，SFU 拓扑最适合连接 4 到 10 个参与者的应用程序，在这些应用程序中，低延迟很重要，或者需要记录并且完整性很重要。这种拓扑通常被认为是最平衡的。

潜在用例的示例包括：

• 医院分诊
• 多方客户服务

多点控制 (MCU) 架构

优点

• 减少所需的参与者上传带宽。
• 允许转码、录制和更广泛的设备支持。
• 每个参与者都将他们的流上传到服务器。
• 服务器处理所有流并将一个发送回每个参与者。

缺点

• 将一些 CPU 负载从患者转移到提供者。

 

在多点控制拓扑中，会话中的每个参与者都连接到充当多点控制单元 (MCU) 的服务器。MCU 接收来自每个参与者的媒体并对其进行解码，将来自参与者的音频和视频混合成一个单一的流，该流又被编码并发送给每个参与者。这需要更少的带宽使用和设备 CPU，但它确实需要额外的服务器 CPU 来将音频/视频混合成单个流。MCU 也是处理不良网络条件的绝佳选择，因为它为每个参与者提供了尽可能低的带宽使用率。

由于这些原因，多点控制拓扑最适合连接大量参与者、需要适应不良网络条件或需要记录且完整性至关重要的大型应用程序。

潜在用例的示例包括：

• 多输入流的大规模广播
• 虚拟教室
• 与偏远地区的客户或动力不足的设备进行视频会议

混合拓扑

混合架构允许您维护选择性转发和多点控制（混合）架构的混合。在混合环境中，拓扑可以随着参与者数量的增加和减少而改变。例如，如果记录很关键，则从选择性转发拓扑开始，然后切换到 10 名参与者数量左右的多点控制拓扑可能是最有意义的。如果成本比记录的完整性更重要，您的应用程序可以从网状拓扑开始，并根据需要进行分级。我们的 LiveSwitch 服务器堆栈是混合拓扑的一个很好的例子，并且是当今市场上为数不多的混合媒体服务器之一。

有关如何扩展 WebRTC 应用程序的更多信息，请查看我们的帖子如何成功扩展 WebRTC 应用程序。

 

  WebRTC安全

WebRTC 本质上是安全 的，并采用了许多保护措施来确保您的数据保持安全。这些包括：

浏览器保护

WebRTC 直接在浏览器之间执行，无需插件。这使得 WebRTC 本质上更安全，因为它为恶意软件或其他可能伪装成插件的不良软件安装提供了额外的保护。由于 WebRTC 是作为浏览器的一部分提供的，因此任何潜在的安全威胁或漏洞往往都可以通过浏览器供应商的自动更新来快速解决。

媒体访问

WebRTC 规范通过要求对要使用的摄像头或麦克风的明确许可，解决了允许访问媒体资源的潜在问题。WebRTC 应用程序不可能在未经同意的情况下访问设备。此外，无论何时使用设备，它都会在客户端 UI 和硬件上显示出来。

加密

加密是 WebRTC 的强制部分，并在建立和维护连接的所有部分强制执行。为此，首选方法是在 DTLS（数据报传输层安全）握手中使用完美前向保密 (PFS) 密码来安全地交换密钥数据。对于音频和视频，密钥数据可用于生成 AES（高级加密标准）密钥，SRTP（安全实时传输协议）又使用这些密钥对媒体进行加密和解密。这种首字母缩略词丰富的技术堆栈转化为极其安全的连接，这些连接是当前技术无法打破的。WebRTC 和 ORTC 都要求使用这个特定的堆栈，该堆栈向后兼容并可与 VoIP 系统互操作。

 

  WebRTC附加组件

虽然 WebRTC 的基础在历史上一直是点对点视频会议，但有许多有前途的附加组件可以帮助 WebRTC 作为实时通信工具变得更加强大。

WebRTC 和广播

当与高效的服务器扩展相结合时，WebRTC 可用于向大量受众提供亚秒级延迟广播。借助台式机和移动设备上每个主要浏览器供应商的无插件支持，再加上智能设计的媒体服务器集群，可以扩展到数千甚至数百万并发用户，同时保持几毫秒的延迟。

WebRTC 和电话 - SIP 和 PSTN

基于 VoIP 的系统和公共交换电话网络 (PSTN) 仍然是许多企业的基本组成部分，并且通常包括对 PBX、网关和 SBC 的大量历史投资。虽然传统的固定电话可能正在逐渐消失，但移动电话仍然无处不在，企业中的 VoIP 部署仍然是标准配置。因此，在某些应用程序中，用户必须能够从电话拨入基于 WebRTC 的活动会话，或者在他们被邀请加入时让他们的电话响铃。

为此，您需要一个网关或交换机，该网关或交换机可以使用随处可见的 VoIP 电话使用的协议——会话发起协议或 SIP。Asterisk 和 FreeSWITCH 等支持 WebRTC 的开源产品有助于小规模部署。在集成此类系统时，利用灵活的 WebRTC 堆栈（例如 LiveSwitch 服务器或云）对于创建无缝用户体验至关重要。

 

  启动WebRTC 项目 

在您进入 WebRTC 项目之前，重要的是要充分了解您的组织的需求、当前的基础架构和可能的限制。很好地掌握您当前的状态和未来的需求将使您能够确定开发自己的视频会议平台有哪些选择。

您需要媒体服务器吗？

在您充分探索您的选择之前，您需要很好地了解您的会话要求。特别是，在任何给定时间，会话中需要连接的最大用户数是多少，您希望他们连接的网络和设备的功能是什么？如果您只需要在视频会议中连接两三个人，并且希望用户都在高速、不拥塞的网络上拥有强大的设备，那么可能不需要媒体服务器。如果您需要连接 4 个或更多参与者，或者如果您将使用旧笔记本电脑或智能手机连接偏远地区的参与者，则需要媒体服务器。请注意，会话需求通常会随着时间而变化，因此请仔细考虑您将来是否需要主持更大的会话。

您想将应用程序托管在云端还是本地？

如果您确定需要媒体服务器，下一步是决定是要将应用程序托管在云端还是本地。每个选项是否有效取决于您的具体要求。

云

当今市场上许多基于 WebRTC 的商业视频会议产品都是基于云的产品。一般来说，对于那些正在寻找一种可以轻松部署并且可以在团队监督最少的情况下快速扩展的解决方案的组织来说，云是很好的选择。考虑基于云的视频会议选项的组织必须仔细检查提供商的数据安全协议以确定风险，以及该产品是否符合 GDPR 等数据保护法。如需完全安全且完全托管的基于云的产品，请查看LiveSwitch Cloud。

本地

媒体服务器也可以在本地托管。对于寻求对其数据进行最大控制的组织来说，这是一个很好的选择。本地解决方案通常会吸引政府、金融机构或医疗保健等规避风险行业的人士。

重要的是要注意“内部部署”可能有点用词不当。虽然一些媒体服务器物理托管在您自己的场所，但其他媒体服务器可以托管在由您的运营团队控制的私有云中。不同之处在于您的组织能够根据自己独特的规范和风险承受能力选择自己的云基础设施提供商。LiveSwitch 的服务器 SDK 完全兼容所有云基础设施提供商，包括 AWS、Azure、Oracle、Digital Ocean 等。在某些情况下，这可能是一个更具成本效益的选择，因为您直接与云提供商打交道，而不是通过第三方。但是，在现场拥有、运营和维护您自己的媒体服务器也会产生可能与您的业务模式相匹配或不适用的成本。

哪种类型的支持 WebRTC 的视频会议最能满足您的需求和您内部的专业知识？

创建视频会议系统有多种选择：从使用开源从头开始创建，到现成的平台以及介于两者之间的一切。下面我们将介绍五种最常见的服务类型。

开源

- 需要熟练的 WebRTC 开发人员

- 可用于开发的时间

- 如果需要，可以舒适地采购媒体服务器

开发人员可用的第一个选项是使用开源代码从头开始构建您自己的平台。 WebRTC 的源代码可供开发人员社区免费使用或修改，因为他们认为合适。如果您有足够熟练的 WebRTC 开发人员来承担该项目（全球不到 12,000 人），有时间致力于应用程序开发，并且很舒服，那么使用可用的开源代码创建自己的应用程序可能是一个不错的选择采购媒体和信令服务器，并且能够驾驭任何开发项目带来的不确定性。

商业 SDK

- 需要熟练的开发人员，但他们不需要是 WebRTC 的专家

- 需要更多地控制他们的解决方案

- 舒适的采购媒体服务器（如果需要）

软件开发工具包 (SDK) 是一组由硬件和软件提供商提供的用于开发应用程序的工具。SDK 在应用程序的客户端运行，通常由应用程序编程接口 (API)、示例代码和文档组成。对于希望对其解决方案进行更多控制的开发人员来说， 使用 SDK 构建视频会议应用程序是一个不错的选择。 它也是希望管理自己的数据中心或云部署的组织的理想选择。 LiveSwitch Server 和LiveSwitch Cloud 是很好的商业 SDK 示例，它们提供不同级别的 WebRTC 功能，可以内置到应用程序中。

 

软件即服务 (SaaS)

- 需要特定的基于云的服务 

- 需要结合其他产品来构建视频会议软件

一些组织可能希望将其 WebRTC 开发的部分外包给其他组织。这些部分作为服务提供，也称为软件即服务 (SaaS)。SaaS 是一种基于云的软件解决方案，它托管应用程序并通过 Internet 向客户提供这些应用程序。可以将 SDK 或开源项目与一些 SaaS 产品相结合。可以作为 SaaS 购买的部分示例包括 TURN 服务器、NAT Traversal 和信令服务器。LiveSwitch Cloud包括可以在其基于 Web 的平台中轻松定制的这些部分。

通信平台即服务 (CPaaS)

- 需要熟练的开发人员（但他们不需要是 WebRTC 专家） 

- 需要更多地控制他们的解决方案

- 想要一个基于云的解决方案

通信平台即服务 (CPaaS) 是指基于云的平台，它使开发人员能够在自己的应用程序中添加语音、视频和消息传递功能等实时通信功能，而无需构建后端基础设施和接口。对于那些希望缩短产品上市时间和前期开发成本同时保持对其解决方案的设计和开发进行高度控制的人来说，使用 CPaaS 是一个很好的选择。由于它是基于云的产品，因此客户需要进行尽职调查以确保云满足所有安全要求。对于正在寻找具有高级功能和分析功能的高度灵活的 CPaaS 平台的任何人来说，  LiveSwitch Cloud都是一个不错的选择。

现成的平台

- 无需熟练的 WebRTC 开发人员

- 可以接受成本

- 不需要应用程序的灵活性 

最后一个选择是购买交钥匙视频会议解决方案。这些解决方案的设计是完全完整的，可供普通消费者在购买时使用。对于无法访问软件开发人员并且愿意为灵活性有限的产品支付更多费用的组织来说，这可能是一个不错的选择。

如果您不确定哪个 WebRTC 选项适合您，请考虑投资 架构评估。 对于那些正在为他们的 WebRTC 项目寻找前进道路的人来说，这是一个很好的第一步。

LiveSwitch 如何帮助我使用 WebRTC？

凭借 10 多年的 WebRTC 经验，我们为合作伙伴提供世界一流的实时通信技术，这些技术经过战略性设计，符合他们的确切规格。我们灵活的平台使我们的团队能够根据您的规格设计完全可定制的直播应用程序。要了解更多信息，请单击入门按钮。

via https://www.liveswitch.io/resource-center/ultimate-guide-to-webrtc