什么是 WebRTC 信令？WebRTC 连接的工作原理

什么是WebRTC信令？

说白了，信令就是计算机如何发现其他使用WebRTC连接的计算机。WebRTC依靠信令服务器来建立对等体之间的连接。

WebRTC让开发者决定如何在对等体之间建立连接。因此，作为WebRTC应用的一部分，谁连接到谁的过程发生在信令服务器上。

信令服务器确定哪些计算机（客户端）相互连接，客户端连接的过程在 WebRTC 下标准化。

但是，如果没有中央信令服务器建立连接，客户端本身就完全无法相互连接。

将 WebRTC 信令服务器视为一种媒人。

请务必注意，WebRTC 信令服务器仅处理有关客户端的元数据或数据。信令服务器本身并不像对等点之间那样直接处理数据流。信令服务器处理如下信息：

• 客户端配置——客户端可以使用什么样的窗口分辨率？Web 应用程序如何连接到该用户的媒体设备（如麦克风和相机）？客户端必须使用哪些编解码器进行媒体播放和流式传输？
• 网络信息– Web 应用程序如何连接到该特定客户端？他们的网络地址是什么？
• 会话信息– 允许流式传输客户端之间的哪种数据？会话何时终止，如何终止？如果参与者断开连接，会话会发生什么情况？

这些是两个连接在连接之前需要知道的事情。按照我们的媒人类比；这有点像安排相亲。

WebRTC 连接的工作原理

WebRTC 中的信令过程在概念上相当简单，但 WebRTC 信令协议实际上在幕后进行了很多工作。

从报价开始

假设客户想要使用使用 WebRTC 的 Web 应用程序；它首先向该 Web 应用程序的 WebRTC 信令服务器发送报价。

Web 应用程序是否具有 WebRTC 信令服务器 nodejs 实现，或者是否使用其他技术（如 PHP）在任何其他框架中实现都没有关系；报价基本上只是有关该客户的信息以及有关如何连接到它的一些信息。

这种向信令服务器提供连接的过程称为会话描述协议或 SDP。

继续握手

因此，信令服务器现在拥有至少一个客户端的信息以及如何连接到该客户端。

信号服务器现在只需要通过交换这些会话描述协议（SDP）提议将两个或更多的客户配对在一起，如果客户接受这些提议，他们将拥有所有需要的信息，以便直接点对点地交换数据。

为了做到这一点，它将第一个客户的SDP要约发送给潜在的对等体，当对等体得到最初的SDP要约时，他们在本地存储该信息，生成他们自己的包含其信息的要约，并将其发送给信令服务器，后者将该信息分发给最初的客户–或者其他想要相互连接的客户。

以连接结束

一旦每个客户端都拥有所有其他连接客户端的 SDP 提议，它们就可以开始点对点连接，而无需使用任何服务器！

此时，客户端知道要连接的其他客户端的列表，但他们需要一个如何连接的计划。 

唯一的收获

没那么快！在现实世界中，一些计算机（客户端）有防火墙或NAT来防止其 IP 地址被公开。这意味着更广泛的互联网无法直接与该计算机通信。

这对于点对点应用程序来说是一个严重的问题！WebRTC 是如何处理这些情况的？

通过 ICE 连接路由 STUN 和 TURN 服务器的逻辑

简而言之

ICE 代表交互式连接建立。将其视为基本意思是“这些客户端相互连接的最佳方式是什么？” ，STUN 和 TURN 服务器正在协助建立这些连接。STUN是一个简单的服务，它提供客户端的公共 IP 作为响应。

客户端需要使用 STUN，因为它们通常位于 NAT 之后，并且不知道它们的公共地址是什么。如果不知道彼此的公共 IP 地址，则无法通过 Internet 建立相互通信。 

不幸的是，在某些情况下，即使知道彼此的公共 IP 地址也是不够的——对称 NAT 就是这样一种情况。对于这些，WebRTC 应用程序通常将TURN服务器作为后备，希望绕过某些客户端的防火墙/NAT。

在具体解决客户端如何通过网络相互寻址时（如不包括媒体和配置数据，如编解码器、对麦克风和摄像头的访问等），还有另外两个服务器发挥作用。STUN 和 TURN。

STUN 服务器

STUN 服务器是低延迟的，处理对等点之间的直接网络寻址信息。因为他们只需要完成这个非常轻的任务，所以他们是首选，因为运行 STUN 服务器的硬件要求非常低。想一想用于运行 WebRTC 应用程序服务的对等点之间面向公众的动态 IP 地址的小 ping。

在某些情况下，这些是独立的、离散的硬件服务器，它们运行以处理 WebRTC 的这一部分——但由于它们的资源需求低，它们可能由同一服务提供商托管，甚至可能与信令服务器本身托管在同一硬件上.

关于 STUN 的一些要点：

• 适用于全锥形 NAT，
• 适用于（地址）-restricted-cone NAT。
• 与端口受限的锥形 NAT 配合使用
• 不适用于对称 NAT
• 使用和维护便宜。

STUN 的问题在于它依赖于每个对等方的清晰和开放的面向公众的 IP 网络地址。并非每个对等点都启用了该功能，因为它们可能位于防火墙后面或使用 NAT 配置，这使得它们无法直接被 WebRTC 应用程序寻址。在这些情况下，需要绕过或绕过限制性 NAT 或防火墙。

TURN 服务器

如果 STUN 服务器无法在所有对等点之间建立直接连接，则 TURN 服务器通常是一种回退方法。TURN 服务器通常是公开注册并列入白名单的第三方服务器，NAT 和防火墙可能会接受来自它们的连接——但它们确实必须实际处理在对等点之间转发媒体流。

关于 TURN 的一些要点：

• 使用对称 NAT
• 是在设备/对等点之间转发/中继数据包的服务器/通道，就像第 4 层的反向代理一样
• 使用和维护昂贵

通过 TURN 服务器处理此原始数据对服务器基础设施提出了额外的网络带宽和成本要求，并且还引入了更多的延迟。

TURN 是一种最好避免的回退方法，但它通常是比完全没有连接更好的替代方法。此外，不能保证任何给定的防火墙或 NAT 配置都将允许所有 TURN 服务器，因此 ICE 需要查看所有可能的连接路由并选择最有效的连接路由。

每个对等点都可以使用的可能连接列表有一个名称，称为ICE candidates。 

有没有更好的方法让开发人员制作点对点网络应用程序？

WebRTC对于开发人员来说完全是复杂的，因为它本质上是作为 Web 浏览器相互通信的兼容层，可以追溯到 Web 2.0。

总体趋势是 WebRTC将更多地转移到 API 服务使用的后端技术，以便为开发人员提供通信平台即服务 (CPaaS)。 

使用这些第三方 API 可以为 Web 应用程序开发人员消除大量的复杂性、安全问题和基础设施部署成本，同时通常还可以为他们的客户提供一套更完善的功能，这些功能已经由专门的软件工程师调试和支持在这个特定的领域，例如实时视频和音频、点对点实时功能（例如群组绘图应用程序）等等。

最重要的是，这些 API 可以将这些经过完善和支持的功能套件的功能扩展到任意 API 端点，例如网页、移动应用程序，甚至是用于功能集成目的的第三方软件。