本文讨论 WebRTC 的实际工作原理——客户端之间如何建立连接。
基本架构
首先看看连接的架构，即两个对等设备之间建立连接所涉及的内容。
上图显示了在两个客户端之间建立连接的各种组件。
逐一定义
1. 信令服务器(Signaling server) – 信令服务器用于管理客户端之间的连接。它用于启用连接、协商连接请求和关闭连接。它使用一种称为 ICE 的协议，该协议收集、交换信息，然后尝试使用 ICE 候选连接会话。虽然目前还没有一个标准的协议来发出应答信号，但常用的协议有：
- 长轮询
- HTTP Streams
- WebSockets
2. STUN server– STUN（Session Traversal Utilities for NAT，会话穿越 NAT 工具）是一种允许客户端发现其公共 IP 地址和所处 NAT 类型的协议。这些信息用于建立客户端之间的连接。在使用 TURN 服务器的情况下，STUN 服务器可能会有 15-20% 的故障。出现这种情况的原因如下：
- 防火墙限制：防火墙可能会阻止与 STUN 服务器的通信，使客户端无法发现自己的公共 IP 地址。
- NAT 设备限制：某些 NAT 设备可能与 STUN 不兼容，或者有妨碍 STUN 功能的特定配置。
- 网络问题：网络拥塞或中断可能会中断客户端与 STUN 服务器之间的通信。
- STUN 服务器超载：如果 STUN 服务器的请求过多，它可能会变得反应迟钝，无法及时提供响应。
3. TURN server – TURN（使用中继 NAT 的遍历）是一种用于中继网络流量的协议。当 STUN 服务器出现故障时就会使用它。它用于在客户端之间传输音频流、视频流和其他实时数据。它不传递信令数据。它有一个公共 IP 地址，客户可通过该地址与其建立连接。这些服务器不是公共服务器，因为通过它们传输的流量会导致产生高昂的费用。
除这些组件外，还有一些重要的协议将完善该架构：
1. UDP – 用户数据报协议是用于所有实时通信的基础协议。虽然 UDP 牺牲了可靠性来换取速度，但轻微的数据包丢失比 TCP 重传造成的延迟要好。这样，即使偶尔会丢失一帧视频，也能确保通话时有更流畅的通信体验。
2. SDP – 会话描述协议就像多媒体通话的菜单。它描述了可用的媒体（音频、视频）、连接方式（编解码器、端口）和定时信息，但并不提供实际的媒体本身。客户端会在连接前交换这些信息。
3. ICE candidates – SDP 描述了媒体本身，但确定如何连接需要更多信息。ICE candidates 就像与 SDP 交换的连接详情，它告诉对等方如何直接或在需要时通过 TURN 服务器相互连接。
在两个客户端之间建立直接连接的步骤
既然我们已经了解了基本架构，知道了所涉及的组件和协议，让我们来看看如何逐步建立连接。
步骤 1：WebRTC Offer
客户端 1 使用会话描述协议（SDP）创建 WebRTC Offer，并将其发送给信令服务器。然后，信令服务器将要约转发给客户端 2。
步骤 2：WebRTC Answer
客户端 2 收到 Offer 后，使用 SDP 创建 WebRTC Answer。该 Answer 会被发送回信令服务器，然后由信令服务器转发给客户端 1。现在，两个客户端都拥有对方的 SDP 信息。
步骤 3：ICE Candidates
客户端 1 和客户端 2 都使用 STUN 服务器收集 ICE 候选者（交互连接建立候选者）。这些候选者包含有关其网络地址和端口的信息。
4. 步骤 4：ICE 候选交换
客户端彼此交换 ICE 候选，可能再次通过信令服务器。在此步骤中可能会进行协商以确定最佳连接方法。
步骤 5：直接连接（首选）
如果候选 ICE 允许客户端之间直接连接，则会建立点对点连接。这是获得最佳性能的首选方案。
步骤 6：TURN 服务器连接（回退）
如果由于网络限制（防火墙、NAT）而无法直接连接，客户端将尝试通过 TURN 服务器进行连接。TURN 服务器充当中继站，在客户端之间转发媒体流量。
现在我们知道如何建立联系，以迎合现实生活中的联系了——显然是使用视频通话。但这可能仅仅是个开始！WebRTC 的潜力远远超出了我们所涉及的范围。敬请期待下一次探索！！！
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/jishu/webrtc/49186.html
