了解 Web 实时通信

介绍

步骤 1：定位对等点

步骤 2：通知对方建立 WebRTC 连接

快速回顾

图片来源

介绍

Web 实时通信 (WebRTC) 是一个正在开发的开源项目，旨在提供 Web 应用程序之间的实时点对点通信。

WebRTC 提供简单的 JavaScript API，帮助开发者轻松构建具有实时音频、视频和数据传输功能的 Web 应用。WebRTC 的最新发展也使其能够集成到原生应用中。由于该 API 的底层机制非常复杂，因此了解 WebRTC 的概念和工作原理对于充分利用这项技术至关重要。

本博客假设读者对 WebRTC 的工作原理一无所知，因此尽可能使用简单的术语和类比来详细解释整个工作原理。让我们开始吧！

为了建立 WebRTC 连接，我们需要执行以下两个步骤：

1. 查找对等点的位置。
2. 通知对方建立 WebRTC 连接。

步骤 1：定位对等点

想象一下打电话，当你需要和某人通话时，你拨打对方的电话号码即可接通。当有人想给你打电话时，也会发生同样的事情。在移动通信中，我们使用手机/电话号码作为用户的身份识别。电信系统还会使用此识别信息来定位用户。

然而，Web 应用程序无法相互“拨号呼叫”。世界上数百万个浏览器并没有分配一个唯一的 ID（就像电话号码一样）。然而，这些应用程序所在的系统会被分配一个唯一的 IP 地址，可以用来“定位”对等体。

然而，这个过程并不像听起来那么简单。因为大多数这类系统都位于网络地址转换 (NAT)设备之后。NAT 设备是为了安全起见，并限制 IPv4 对可用公网 IP 地址的限制。NAT 设备会为本地网络中的系统分配私有 IP 地址。这些私有 IP 地址仅在本地网络中有效且可见，并且无法用于接收来自外部世界的通信，因为网络外部的系统无法识别网络内设备的公网 IP。

由于NAT设备的介入，对等体无法知道自己的公网IP地址，因为它被NAT分配的私网IP地址屏蔽了。因此，它无法与其他对等体共享其公网IP地址来接受连接。更通俗地说，如果你想让别人给你打电话，你需要把你的电话号码告诉对方。但是，在NAT的存在下，这就像住在酒店里，你的房间电话号码对外界是隐藏的，打到酒店的电话会在前台处理，并根据你的要求转接到你的房间。这种间接的连接方式并非点对点连接技术的目标。

为了解决这个问题，我们使用了一种称为交互式连接建立 (ICE) 的协议。ICE 的作用是找到连接两个对等体的最佳路径。ICE 可以执行直接连接（即在没有 NAT 的情况下），也可以执行间接连接（即存在 NAT 的情况下）。ICE 框架为我们提供了“ICE 候选”。“ICE 候选”只不过是包含我们自己的公共 IP 地址、端口号和其他连接相关信息的对象。

在没有 NAT 的情况下，ICE 非常简单，因为对方的公网 IP 地址很容易获取。然而，在存在 NAT 的情况下，ICE 依赖于名为“NAT 会话遍历实用程序 (STUN)”和/或“使用中继绕过 NAT 的遍历 (TURN)”的实体。

STUN 服务器基本上允许对等体找到其自身的公网 IP 地址。需要知道自己公网 IP 地址的对等体会向 STUN 服务器发送请求。STUN 服务器会回复该对等体的公网 IP 地址。现在，此公网地址可以与其他对等体共享，以便他们找到您。但是，如果对等体位于复杂的 NAT 和/或防火墙之后，即使 STUN 也无法找到并向请求对等体提供其 IP 地址。在这种情况下，ICE 依靠 TURN 来建立连接。顾名思义，TURN 是一个中继服务器，当两个对等体之间无法建立直接连接时，它可以充当传输数据、音频和视频的中介。

STUN 服务器仅在查找公网 IP 的过程中起作用。一旦 WebRTC 连接建立，所有后续通信都将通过 WebRTC 进行。但是，对于 TURN，即使在 WebRTC 连接建立之后，也始终需要 TURN 服务器。

TURN 服务器并非我们设计的目标，但由于 STUN 的限制，我们不得不依赖它。STUN 服务器的成功率仅为 86%。

“ICE 很复杂，因为我们生活在一个复杂的世界。”

步骤 2：通知对方建立 WebRTC 连接

现在我们已经获得了ICE候选，下一步是将这些候选发送给我们希望连接的对等节点。除了候选之外，会话描述（例如会话信息、时间描述和媒体描述）也会一起发送。ICE候选和会话描述会捆绑在一个对象中，并使用会话描述协议 (SDP)进行传输。在某些情况下，ICE候选不会与会话描述捆绑在同一个对象中，而是单独发送，这种情况称为涓流ICE（这是一个全新的概念，我们暂时不深入探讨！）。

我写过我们需要将信息“发送”给对方。但是，当我们只知道发送方的 IP 地址，而不知道接收方的 IP 地址时，候选集和会话描述该如何传输呢？而且，由于 WebRTC 连接尚未建立，这些信息将通过什么媒介传输呢？

所有这些问题的答案都蕴含在一个称为“信令机制”的概念中。在建立 WebRTC 连接之前，我们需要某种媒介在对等体之间传输上述信息，并让它们知道如何定位并建立 WebRTC 连接。这时，信令机制就应运而生了。顾名思义，信令机制会在两个想要建立连接的对等体之间交换连接信号（ICE 候选、会话描述等）。

WebRTC 没有定义任何实现此类信令机制的标准，而是让开发者自行选择机制。交换信息的信令机制可以通过简单地将信息复制粘贴到相应的对等端来实现，也可以通过使用 WebSockets、Socket.io、服务器端事件等通信通道来实现。简而言之，信令机制只是对等端之间交换连接相关信息的一种方式，以便对等端能够相互识别并开始使用 WebRTC 进行进一步通信。

快速回顾

让我们快速逐步地浏览整个过程以便更好地理解。

假设对等体A想要与对等体B建立 WebRTC 连接，则他们需要执行以下操作：

1. 对等体A使用交互式连接建立 (ICE)生成其 ICE 候选。大多数情况下，它需要NAT 会话遍历实用程序 (STUN)或NAT 中继遍历 (TURN)服务器。

2. 对等体A将 ICE 候选和会话描述捆绑成一个对象。该对象作为本地描述（对等体自身的连接信息）存储在对等体 A 内部，并通过信令机制传输给对等体 B。这部分内容称为Offer。

3. 对等体B收到该请求，并将其存储为远程描述（即另一端对等体的连接信息），以供后续使用。对等体B生成自己的 ICE 候选和会话描述，并将其存储为本地描述，并通过信令机制发送给对等体A。这部分称为应答。（注：如前所述，步骤 2 和步骤 3 中的 ICE 候选也可以单独发送）

4. 对等体A接收来自对等体B 的答案并将其存储为其远程描述。

这样，双方就拥有了彼此的连接信息，并可以成功开始通过 WebRTC 进行通信！

图片来源

1. https://html5-chat.com/blog/wp-content/uploads/2018/01/webrtc.jpg

2. https://i.stack.imgur.com/qQuEV.gif

3. https://www.avaya.com/blogs/wp-content/uploads/2014/08/stun3.jpg

4. https://www.kirupa.com/html5/images/signaling_server.png