搭建WebRTC视频会议应用系列1：WebRTC架构

搭建WebRTC视频会议应用系列的第 1 部分介绍了 WebRTC 的一些核心概念，如信令、SDP、ICE 协议、STUN 和 TURN 协议、数据通道，并讨论了基本的应用工作流程。

近来，WebRTC 框架在实时通信领域大受欢迎。全球大部分浏览器支持 WebRTC。Google Meet、Discord 和 Amazon Chime 等一些著名的实时通信应用程序都采用了这项技术。

最近，我有机会参与了一个 WebRTC 项目，学习到了很多关于实时视频流的新知识。由于 WebRTC 的文档对于本地应用程序来说并不是很完善，因此在项目实施过程中遇到了一些挑战。因此，我想通过一系列文章与大家分享我在 WebRTC 工作中的一些心得体会。让我们直接进入主题。

什么是 WebRTC？

WebRTC 是一个开源框架，可在网络浏览器和本地设备上实现实时通信和会议应用，无需中间服务器。哇哦真是寥寥数语。让我们来深入了解一下 WebRTC 的各项特性。

开源框架： WebRTC 是谷歌在 2011 年制定的一项开放标准，目前仍在不断改进中。它是一套将以前存在的协议组合在一起的协议，用于实现实时通信。

实时通信和会议： WebRTC 框架可实现小于 500 毫秒的延迟，是实时通信的理想解决方案。这里需要注意的一点是，实时通信不同于直播。实时通信涉及人与人之间的互动，需要超低的延迟时间，而直播则需要 1-30 秒的延迟时间。

设备支持：许多现代浏览器都支持 WebRTC，如 Chrome、Firefox、Safari、Edge、Opera 等（因为它的名字里有 “Web”！）。虽然它最初是为网络开发的，但也支持 C++ 本机 API。这些 API 也被移植到了 Android 和 iOS 平台上，使其成为最普遍的实时通信框架之一。

无服务器媒体通信： WebRTC 基于点对点架构，无需中央服务器来交换视频和音频数据。无需服务器大大降低了应用程序开发人员的成本。这里有一些问题。

我们仍然需要一个服务器，以便对等方可以在传输媒体之前找到彼此（使用称为信令的过程）。
要在 NAT 后面的对等方之间建立连接，可能需要 STUN 服务器。
如果对等点无法直接相互通信，我们可能需要一台服务器来中继媒体数据。

我们将在后面的文章中进一步了解这些情况。

WebRTC 框架开箱即带实时通信所需的所有必要模块。它不需要安装其他编解码器、插件或第三方软件。WebRTC 支持一些著名的编解码器，包括 VP8、VP9、H.264、H.265 等。

安全性： WebRTC 在构建时充分考虑了安全性。使用该框架通信的所有媒体默认都经过端到端加密。

现在，我们对 WebRTC 的功能有了稍微深入的了解，下面让我们来了解一下 WebRTC 的架构组件。

WebRTC 架构

使用 WebRTC 需要了解一些基本的架构构件（我可没说这很容易）。其中包括：

PeerConnection： WebRTC 的主要 API 通过 PeerConnection 类公开。该类封装了媒体流设置的主要部分，包括协商媒体要求、与对方建立连接、编码、解码、传输数据、带宽估算等。

信令：信令是对等体（对等体连接）就如何通信和通信内容交换信息的协议的一个别称。信令是在带外进行的，这意味着 WebRTC 并未规定如何交换信令信息。信令可以通过服务器发送，我们甚至可以把信令数据写在明信片上，然后发送给 WebRTC 所关心的另一个对等体（不过这样做就不再是实时的了）。信令交换规范的缺乏为开发人员提供了很大的灵活性。我个人开发了一个 WebRTC 应用程序，它可以在本地 Wi-Fi 网络上完全脱机运行，无需联网。信令主要包括会话描述协议（SDP）和候选 ICE 的交换，具体描述如下。

会话描述协议（SDP）： SDP 用于协商交换的媒体信息。SDP 数据包含传输的媒体（视频/音频）、用于传输媒体的协议（视频、音频和数据通道可使用 SRTP、SCTP、DTLS 等不同协议）、使用的端口、支持的编解码器、编解码器参数等详细信息。如前所述，SDP 交换是信令的一部分。发起对等端创建包含上述信息的 SDP 报文并发送给另一个对等端，另一个对等端查看 SDP 报文并生成自己的答复，然后发回给发起对等端，从而完成协商。

交互式连接建立（ICE）： ICE 协议用于在两个对等点之间建立连接。之所以需要 ICE，是因为 IPv4 网络中的 NAT 使位于 NAT 后面的对等网络难以直接相互连接。ICE 提供了一种机制，即使对等网络位于 NAT 后面，也能通过这种机制相互连接。作为 ICE 协商的一部分，首先要在每个对等点收集一组 ICE 候选者，并与另一个对等点交换。一个 ICE 候选者代表了有关对等网络可能连接方式的信息。然后，对每组本地和远程 ICE 候选者进行连接性检查，最后商定一对 ICE 候选者进行媒体交换。媒体交换路径将在 ICE 协商完成时建立。

根据每个对等方所属的网络，由此建立的连接可分为三类。它们是：

如果对等点无需穿越 NAT 即可相互连接，则使用主机 ICE 候选协议
如果对等点可以通过穿越 NAT 达到对方，则使用 STUN 协议（解释如下
如果对等网络无法通过 NAT 穿越相互连接，则使用 TURN 协议（解释如下）的中继服务器

NAT 会话穿越实用程序（STUN）：如果没有 STUN，NAT 后面的两个对等设备就无法互相访问对方的 IP 地址。要实现直接连接，它们首先需要连接到一个可公开访问的 STUN 服务器。这就在 NAT 服务器上创建了一个孔（从技术上讲，孔是从网络本地主机和端口到可公开访问的主机和端口的映射）。然后，使用信令作为 STUN ICE 候选者与另一个对等设备交换有关该保持的信息，之后就可以建立连接了。连接建立后，媒体将利用 NAT 中的保留直接与对方交换。

使用中继穿越 NAT (TURN)： STUN 连接的建立并不适用于所有类型的 NAT。如果对端位于对称 NAT（一种更安全的 NAT）后面，则无法使用 STUN 建立连接。在这种情况下，应用程序必须依赖称为 TURN 服务器的中继服务器来交换媒体。对等设备将首先与 TURN 服务器建立连接，并通过作为 TURN ICE 候选者的信号与另一个对等设备共享连接信息。然后，另一个对等端可以与中继服务器建立连接并传输媒体。在这种情况下，媒体不会传输到对等端，而是通过中继服务器发送，这可能会产生额外的费用。许多提供 WebRTC 服务的公司会向客户收取这些中继服务器的费用。