WebRTC：标准、技术和开发者生态系统

实时通信已成为我们通过互联网进行互动的重要方式。从视频通话和直播到互动游戏和即时消息，我们一直依赖于可靠的即时信息交流。WebRTC 是一种变革性的技术标准，可直接通过Web浏览器实现实时通信，而无需额外的软件。

在本篇文章中，我们将深入探讨 WebRTC 的本质，探索其标准、技术框架以及支持其发展和创新的不断壮大的开发者生态系统。

什么是 RTC，为什么我们希望它成为“Web”？

WebRTC 是 Web Real-Time Communication 的缩写。其目标是为 Web 浏览器和任何类型的软件应用程序提供实时通信功能。

实时通信（RTC）指的是在网络上进行无感知延迟的信息交换。这种信息通常涉及视频和音频，但也适用于任何类型的数据。RTC 的最常见应用是视频会议、互动直播、文件共享、即时消息和云游戏。

要了解 WebRTC 的重要性，我们需要追溯到 2000 年代中后期，准确地说，当时的实时通信需要安装特定的应用程序，而这些应用程序往往不能在所有平台上使用，在某些情况下仅限于少数用户使用。

即使是基于浏览器的解决方案，也需要安装额外的授权软件或专有软件，而这些软件往往存在安全问题或漏洞，会破坏使用体验。

由于这些限制，开发人员需要一个通用框架来构建功能强大且安全的 RTC 应用程序，这些应用程序可以在任何地方运行，而且不需要用户安装额外的软件。

这些情况促使谷歌在收购 Global IP Solutions 公司后，于 2011 年发布了基于浏览器的实时通信开源项目 WebRTC。

WebRTC 作为标准

随着 WebRTC 的到来，万维网联盟（W3C）和互联网工程任务组（IETF）也开始了标准化工作。W3C 定义了开发人员用来构建应用程序的 API ，而 IETF 则定义了能够在网络上交换数据的网络协议。

历时十年！直到 2021 年初，WebRTC 规范才从 “拟议推荐 “转变为 “推荐”。这一身份为 WebRTC 提供了 W3C 的认可，意味着在确保不同浏览器和平台之间的互操作性方面向前迈进了一大步。

WebRTC 标准描述了一些关键组件，如建立点对点（p2p）连接的细节、处理媒体内容的方法以及直接数据交换的规范。它通过加密确保通信安全，并纳入了权限管理和用户同意机制。

该规范还列出了 IETF 定义的相关协议，如 RFC8825： “概述： 基于浏览器应用的实时协议 “和 RFC8826 “WebRTC 的安全注意事项“。

规范中有意省略了连接前协商过程的定义机制，即 “信令”。这是一个关键步骤，因为它允许对等方交换能实现通信的信息，如每个客户端的一对 IP 地址和端口（也称为 ICE 候选）、要使用的编解码器和加密细节。

相反，信令机制的实施则由开发者负责。常见的信令解决方案包括 WebSockets、SIP 和消息代理。

WebRTC 作为一种技术

除了该标准之外，大多数现代浏览器都采用了名为 libWebRTC 的开源技术。它提供了开发人员用来构建应用程序的 Javascript API。我们在文章《Native WebRTC 开发：libWebRTC 和替代方案指南》中介绍了这一技术以及在浏览器之外实现此类功能的其他 WebRTC 实现。

这样的 API 包括用于访问摄像头和麦克风的 getUserMedia、用于访问设备屏幕内容的 getDisplayMedia、用于建立呼叫的 RTCPeerConnection 和用于双向数据传输的 RTCDataChannel 等组件。

值得注意的是，使用 WebRTC 构建实时通信应用所涉及的工作远不止调用 API 中的组件。其他工作包括执行信令、配置穿越网络地址转换（NAT）的设置以及媒体处理和路由。

WebRTC 开发者生态系统

虽然完全使用内部开发的工具也能构建 WebRTC 应用程序，但常见的做法是利用第三方工具和库，这样既能加快开发速度，又能依靠成熟的解决方案。通常的做法是利用第三方工具和库，这样开发人员既能加快开发速度，又能依赖成熟的解决方案。

此外，这些工具通常还提供自己的 API 组件客户端抽象。这种抽象便于与特定解决方案进行交互，并使 API 适应 React 或 Vue 等最新Web开发技术。

这一系列外部解决方案为围绕 WebRTC 的整个生态系统奠定了基础。该生态系统主要由以下部分组成：

客户端库

如前所述，一些第三方库从应用程序接口中抽象出了一些组件，为实现这些功能提供了一种更简单或量身定制的方法。客户端库通常针对特定的应用栈，例如 React Native 应用程序使用 react-native-webrtc 库。

信令库

这些是客户端库的子集，其目标是将 WebRTC 应用程序与信令机制集成。例如 SIP.js 和 socket.io，它们分别提供了与会话发起协议（SIP）和 Socket.IO 服务器的集成。

媒体服务器

媒体服务器提供服务器端 WebRTC 接口，允许实施多点控制单元（MCU）和选择转发单元（SFU）架构。它们可实现更高级的功能，如多方通话、服务器端录音、桥接其他电话系统或对媒体流进行特定处理。例如 Janus、mediasoup 和 LiveKit。

ICE 服务器

这些工具可帮助 WebRTC 应用穿越 NAT 限制，向对等方提供 ICE 候选者，并在无法直接连接时转发媒体流量。一个典型的例子就是 Coturn。

WebRTC 架构

构建 WebRTC 应用程序需要结合多种解决方案和工具，每种解决方案和工具都设计用于执行特定任务。这些基于 WebRTC 标准和技术的组件相互配合，最终实现对等方之间的通信。

对于缺乏适当专业知识的公司来说，尤其是在大规模运行的情况下，配置复杂的架构可能是一项巨大的挑战。在这种情况下，有一种更简单的方法，即通信平台即服务（CPaaS）。

在这种方法中，用户无需自己配置 WebRTC 基础设施并处理上述复杂问题，而是通过简单的 API 将应用程序连接到提供商的平台。

挑战与趋势

自 WebRTC 首次发布以来，十多年过去了。从那时起，我们通过互联网进行交互的方式有了进一步发展，而 WebRTC 已经能够适应其中的大部分变化。但是，WebRTC 未能为所有使用案例提供完美的解决方案。

直播流媒体就是一个典型的例子。虽然 WebRTC 提供了一种能实现交互式体验的低延迟方法，但它还不能完全与 HLS 和 RTMP 等其他流媒体协议相提并论。尽管会增加一些延迟，但这些协议支持的受众范围更广。

此外，如今的实时通信应用已不仅仅局限于视频会议，还包括从云游戏到远程桌面应用等各种应用。此类用例通常不需要 WebRTC 的所有功能，但开发人员往往最终不得不实现整套功能，以便提供 FlexFEC 和自适应比特率等功能。

这两种情况都导致了与 Web 实时通信功能相关的新趋势和解决方案的发展。

其一是将 WebRTC “拆分 “成更小的部分：

• 用于管理网络媒体发送的 WebTransport
• 用于编码/解码媒体的 WebCodecs
• 作为粘合剂的 WebAssembly，用于管理丢包、重传、回声消除等。

其他新发展更侧重于为直播流媒体使用案例提供更优化的方法，如 Media over Quic (MoQ)、WHIP 和 WHEP。

还有人工智能（AI），虽然与 WebRTC 没有直接关系，但它正成为各行业和产品的必备功能。实时通信也不例外，人工智能正被越来越多地集成到视频会议应用和联络中心解决方案等产品中，以增强其功能和用户体验。

人工智能和 WebRTC 的常见应用包括让人工智能在幕后增强媒体压缩和处理功能，以及实现背景消除、转录和情感分析等通话中功能。

WebRTC 并不是一个放之四海而皆准的解决方案。幸运的是，新的趋势和技术正在出现，以填补任何空白。

作者：Hector Zelaya
译自：https://webrtc.ventures/2024/07/webrtc-a-standard-a-technology-and-a-developer-ecosystem/