前言

继 《WebRTC 探索：前端视角下的实时技术解析（上）》 一文之后，我们已经对 WebRTC 的基础概念和 API 有了初步的了解。在本文中，我们将进一步挖掘 WebRTC 的核心技术，探索其在前端开发中的应用潜力。随着实时通信技术的飞速发展，WebRTC 已经成为现代网络应用的关键技术之一。接下来，让我们深入探讨WebRTC 的核心技术及其实现细节。

1、WebRTC 连接：核心概念与实现

在 WebRTC 中， PeerConnection 是实现点对点（P2P）视频通话的核心 。要全面理解 PeerConnection的工作原理，首先需要掌握一些关键概念和连接方式。以下是这些核心术语的解释，以及在不同网络环境下建立 WebRTC 连接的方式。

1.1 核心概念

理解 PeerConnection 的运作需要了解以下关键术语：

总结 ：

• SDP 是信令过程中交换的会话描述数据格式，用于确定多媒体会话的参数。
• 信令 是WebRTC连接建立前的控制信息交换机制，涉及SDP的创建和交换。
• ICE 协议通过收集和测试网络 Candidate 来实现NAT穿透，以建立点对点连接。
• Offer 和 Answer 是SDP交换的一部分，分别由发起方和接收方创建，以协商会话的媒体参数。

1.2 PeerConnection 的核心方法和事件

PeerConnection 是 WebRTC 中用于建立和维护点对点连接的关键 API。以下是其核心方法和事件：

核心方法：

核心事件：

通过这些方法和事件，PeerConnection 可以高效地建立和管理 P2P 连接，实现媒体流的传输以及数据通道的管理。通过 信令 机制，客户端 A 和客户端 B 交换 SDP 和 ICE 候选信息 ，完成连接的建立和维护。

1.3 WebRTC 的连接方式

在建立 WebRTC 连接之前，客户端 A 和客户端 B 通常需要通过信令服务器交换必要的连接信息。信令服务器负责在客户端之间传递连接所需的信息，包括 SDP（Session Description Protocol） 和 ICE（Interactive Connectivity Establishment） 候选信息。根据不同的网络环境，WebRTC 选择合适的连接方式来建立和维护点对点连接。

1.3.1 通过本地网络直接连接

当两个设备位于同一个局域网内（例如家庭网络或办公室网络）时，它们可以直接通过对等连接进行通信，而无需经过中间服务器。这种连接方式充分利用了本地网络的低延迟和高速特性，实现快速的数据传输和实时通信。

1.3.2 通过公共 IP 地址 Internet 直接连接

当两个设备不在同一局域网内时，它们需要通过公共 IP 地址进行互相访问。设备之间的直接连接依赖于公共 IP 地址，但设备通常不知道它们在互联网上的公共 IP 地址。因此，需要使用 STUN 服务器 （Session Traversal Utilities for NAT）来帮助设备发现自己的公共 IP 地址，从而建立连接。

STUN 服务器 的主要作用是：

• 发现公共 IP 地址并协助 NAT 穿透 ：STUN 服务器帮助设备识别它们在互联网中的公共 IP 地址，尤其是在 NAT 环境下。这一过程有助于设备之间建立点对点连接，从而实现网络通信。

然而，即使有 STUN 服务器的帮助，这种连接方式仍可能受到 NAT 和 防火墙 的限制：

• NAT（网络地址转换） ：NAT 可能会对设备的公共 IP 地址进行修改，从而影响连接的稳定性。
• 防火墙 ：防火墙可能阻止某些类型的网络流量，影响设备之间的直接通信。

1.3.3 通过 TURN 服务器路由连接媒体

在某些情况下，P2P 连接可能会失败，尤其是当 NAT 和防火墙设备不允许直接流量时。此时， TURN 服务器 （Traversal Using Relays around NAT）可以作为中间服务器来转发数据。

TURN 服务器 的作用是：

• 中继数据 ：在 P2P 连接不可用时，TURN 服务器接收和转发媒体流，从而保证通信的连续性。

虽然 TURN 需要额外的带宽成本，但它确保了在 P2P 连接不可用时，音视频数据仍能通过服务器转发，从而保证通信的连续性。

1.4 信令服务器与 STUN/TURN 服务器的协作

在 WebRTC 会话中，信令服务器负责交换建立连接所需的信息，包括 SDP 和 ICE 候选信息。STUN 服务器帮助发现公共 IP 地址，TURN 服务器在 P2P 连接失败时提供备选路径。通过理解这些连接方式和信令过程，我们可以更好地应对不同网络环境下的通信挑战，优化 WebRTC 的实时通信体验。

2、WebRTC p2p会话连接流程

在深入探索了 PeerConnection 的概念之后，我们现在转向WebRTC技术的核心——会话的建立过程。WebRTC的P2P架构允许在用户之间直接建立通信，无需经过中心服务器。以下是对WebRTC呼叫流程的详细描述，它将揭示如何从初始设置到成功建立连接的每一个步骤：

WebRTC 呼叫流程：

1. 连接信令服务器

• Peer A（呼叫端） 和 Peer B（被呼叫端） 首先分别与信令服务器建立连接。信令服务器充当通信的桥梁，负责转发信令消息。

• Peer A 启动通话过程，创建一个 RTCPeerConnection 对象。这个对象是WebRTC中的核心，负责管理通话。

• Peer A 调用 createOffer 方法生成一个会话描述（SDP Offer），描述了它希望如何进行通信，例如使用的编解码器、带宽等。
• 调用 setLocalDescription 方法设置本地会话描述。
• 通过信令服务器将 SDP Offer 发送给 Peer B 。

• Peer B 接收到 SDP Offer 后，通过 setRemoteDescription 方法设置远程会话描述。
• 接着， Peer B 创建自己的 RTCPeerConnection 对象，并创建 SDP Answer 响应 Peer A 的Offer。
• 调用 setLocalDescription 设置本地会话描述。
• 通过信令服务器将 SDP Answer 发送回 Peer A 。

• Peer A 接收到 SDP Answer 后，通过 setRemoteDescription 方法设置远程会话描述，完成会话的建立。

• Peer A 和 Peer B 各自开始收集ICE候选信息，这些信息描述了可能用于建立连接的网络路径。
• 收集完毕后，双方通过信令服务器交换ICE候选信息。
• 接收到ICE候选后，使用 addIceCandidate 方法将其添加到 RTCPeerConnection 对象中。

• 完成ICE候选交换后， Peer A 和 Peer B 尝试使用这些候选建立P2P连接。
• 如果成功，将建立起用于媒体流传输的P2P通道。

WebRTC呼叫流程是一个涉及信令交换、SDP协商、ICE候选收集和交换的复杂过程。通过这个流程，WebRTC能够在不同设备之间建立起安全的点对点媒体流传输，实现高质量的实时通信。

请注意，实际的WebRTC应用可能还需要考虑更多细节，例如信令的具体格式、ICE候选的类型和优先级、以及如何在实际应用中处理各种网络条件。