什么是 WebRTC 信令？WebRTC信令服务器原理

什么是 WebRTC 信令？说白了，信令是计算机如何使用 WebRTC 发现其他计算机来连接的。

什么是 WebRTC？

WebRTC 是一个由 Google 拥有和维护的开源项目，它构建了许多互联网的点对点应用程序。

虽然 WebRTC 作为一个项目是开源的并且可以被公众审计，但这并不能自动使每个使用 WebRTC 的应用程序都开源；由于连接管理的实现留给应用程序开发人员，这使得并不是每个 WebRTC 信令服务器都是开源的。

对等应用程序是用户的计算机直接相互通信，而不是通过中央服务器进行通信的应用程序。这极大地节省了服务器基础设施资源，并且是一种非常有效的方式，可以将实时视频和语音等功能融入您最喜爱的互联网应用程序。

对于非开发人员或初级开发人员来说，理解 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 服务器

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

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

关于 STUN 的一些要点：

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

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

转服务器

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

关于 TURN 的一些要点：

• 与对称 NAT 一起使用
• 是在设备/对等体之间转发/中继数据包的服务器/通道，例如第 4 层的反向代理
• 使用和维护成本高

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

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

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

开发人员是否有更好的方法来制作对等网络应用程序？

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

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

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

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

作者：Digital Samba