WebRTC第一课：从信令、ICE到NAT穿透的连接建立全流程-优快云博客

请点击上方蓝字TonyBai订阅公众号！

在上一篇文章《WebRTC第一课：网络架构与NAT工作原理》中，我们介绍了WebRTC的网络架构和NAT的基本概念，学习了WebRTC采用端对端（P2P）的通信模型，知道了NAT（网络地址转换）的概念以及给像WebRTC这样的直接P2P通信带来的挑战。

在实际的网络环境中，建立WebRTC这样的端到端连接的确并非易事。因此，在这篇文章中，我将继续上一篇文章的内容，全面探讨一下WebRTC连接建立的全流程，涵盖信令交换、ICE候选信息采集和选择、NAT穿透的各个关键步骤，希望能给大家理解WebRTC技术栈带去帮助。

1. WebRTC连接建立概览

在深入细节之前，我们先用一个时序图来概览WebRTC连接建立的主要步骤：

注：上图由mermaid^[1]生成，对应的脚本在webrtc-first-lesson/part2/process-overview.mermaid。

这个过程可以概括为以下几个主要步骤：

信令交换：客户端通过信令服务器交换必要的连接信息，包括会话描述协议（SDP）数据。
ICE候选收集：每个客户端收集可能的连接方式（称为ICE候选）。
候选交换：通过信令服务器交换ICE候选信息。
连通性检查：客户端尝试各种可能的连接方式。
建立P2P连接：选择最佳的连接路径，建立直接的端到端连接。

在这个过程中，我们会涉及到几个关键概念：

信令（Signaling）：用于协调通信并交换元数据的过程。
ICE（Interactive Connectivity Establishment）：一种用于在各种网络情况下协助建立端到端连接的框架。
NAT穿透（NAT Traversal）：克服网络地址转换带来的通信障碍的技术。

接下来，我们将详细探讨这些概念，并基于这些概念详细说明WebRTC建连的全流程。

我们先来看看信令(Signaling)。

2. 信令：WebRTC连接的基础

WebRTC技术栈中**唯一没有标准化的就是信令(Signaling)**，但信令却又是WebRTC连接的基础和必不可少的部分。

信令是WebRTC中用于协调通信过程的“指令”，它负责在对等端之间交换建立连接所需的元数据，但不会直接传输音视频数据。信令的主要作用包括：

交换会话描述协议（SDP）信息
交换网络配置信息（ICE候选）
协调会话的开始和结束
处理错误和会话状态变化

WebRTC本身并未定义信令协议标准，这主要考虑的是信令的设计与实现依赖于具体应用的需求，同时也有兼容性方面的考虑，比如：使WebRTC能够与现有的通信系统集成。在安全性方面，自定义信令也可以允许应用层来控制如何交换敏感信息。

目前用于WebRTC信令协议实现的常见方案主要包括基于WebSocket的自定义协议、SIP协议(Session Initiation Protocol)以及一些像XMPP(eXtensible Messaging and Presence Protocol)这样的成熟的即时通讯协议等。

就我个人而言，SIP和XMPP这样的传统协议都太重了，协议自身理解起来就有门槛！基于WebSocket的自定义协议，既简单又灵活，适合大多数业务不那么复杂的场景，在本文中，我们的信令协议就基于WebSocket自定义协议来实现。

Why Websocket？用WebSocket承载自定义信令协议的主要原因是几乎所有现代浏览器和后端框架都支持WebSocket，并且它是全双工通信，允许服务器和客户端随时发送消息，并且建立连接后，消息交换的开销也很小。

在设计信令语义时，我们通常会采用“Room”这个抽象模型来管理参与通信的客户端，这与WebRTC常用于互联网音视频应用不无关系。Room模型有助于组织和管理多个参与者，控制消息的广播范围，并可以实现更复杂的通信场景（如多人会议系统）。

下面是基于Room模型设计的信令交互的典型流程：

注：上图由mermaid^[2]生成，对应的脚本在webrtc-first-lesson/part2/signaling-room-model-flow.mermaid。

下面对图中几个关键流程做一些简要说明：

房间创建

Client1向SignalingServer发送创建房间的请求，SignalingServer创建房间并返回房间ID给Client1。

客户端加入

Client2使用房间ID向SignalingServer发送加入房间的请求，SignalingServer通知Client1有新客户端加入。SignalingServer向Client2确认加入成功，并返回房间信息。重复相同的过程，Client3也如此加入了房间。

WebRTC连接建立（以Client1和Client2为例）

Client1创建Offer并通过SignalingServer向Client2发送Offer，SignalingServer将Offer转发给Client2。Client2创建Answer，并通过SignalingServer向Client1转发Answer。之后，Client1和Client2还会以类似的方式互相交换ICE候选信息，通过SignalingServer进行转发。

注：offer是由发起者（通常是调用方）创建的SDP（Session Description Protocol）消息，表示希望建立的媒体会话的描述。answer是由接收者（通常是被叫方）回复的SDP消息，表示其对offer的响应。SDP中通常包含媒体格式、网络信息、编解码器等详细信息，供双方协商和确认，具体可参考我之前的文章《使用Go和WebRTC data channel实现端到端实时通信^[3]》。