信令（Signaling）

什么是信令？

信令是允许两个 WebRTC 对等点相互发现并交换建立直接点对点连接所需信息的过程。可以把信令想象成初次打电话约见面——你还没到见面地点，只是在协调在哪里、什么时候见面。

当你想与某人开始视频通话时，你的浏览器并不神奇地知道对方的 IP 地址、支持什么视频编解码器，或如何穿过防火墙到达对方。信令就是在 WebRTC 建立实际媒体连接之前，在两个对等点之间交换这些关键设置信息的信使服务。

有趣的是，WebRTC 刻意没有规定信令应该如何工作。你可以使用 WebSocket、HTTP 长轮询、服务器推送事件，甚至信鸽——WebRTC 不在乎。这种灵活性是有意为之，允许开发者将 WebRTC 集成到现有架构和通信系统中。

为什么需要信令

WebRTC 实现点对点连接，意味着你的浏览器直接与对方的浏览器通话，媒体不经过服务器（大多数情况下）。但这里有个悖论：要建立直接连接，两个对等点首先需要了解对方。

你的 WebRTC 客户端最初一无所知。它不知道：

你想连接谁
对方在哪里（IP 地址）
对方支持什么媒体格式（编解码器）
如何穿过 NAT/防火墙到达对方
安全通信使用什么加密密钥

信令提供了一个中立的会面地点——信令服务器——双方对等点可以在此交换这些引导信息。一旦他们拥有足够的对方信息，就可以尝试建立直接连接，信令服务器的工作就完成了（尽管它通常保持可用以协调通话期间的变化）。

信令工作原理：提供/应答交互

WebRTC 信令遵循一种称为提供/应答模型的模式，借鉴自 SIP（会话初始协议）。以下是分步过程：

1. 对等点 A 创建提供

发起通话的对等点（对等点 A）通过在其 RTCPeerConnection 对象上调用 createOffer() 创建 SDP 提供。此提供包含：

支持的音频和视频编解码器（H.264、VP8、VP9、Opus 等）
媒体能力（分辨率、帧率）
加密密钥（用于保护连接的 DTLS 指纹）
网络传输详情
会话元数据

提供格式化为 SDP（会话描述协议），一种基于文本的格式，看起来像这样：

v=0
o=- 123456789 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
m=audio 9 UDP/TLS/RTP/SAVPF 111 103
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:abcd
a=ice-pwd:efgh1234
a=rtpmap:111 opus/48000/2
m=video 9 UDP/TLS/RTP/SAVPF 96 97
a=rtpmap:96 VP8/90000
...

2. 通过信令通道发送提供

对等点 A 将此提供设置为其本地描述（setLocalDescription()）并通过信令通道发送给对等点 B。这可以是 WebSocket 消息、HTTP POST 请求、消息队列——应用程序用于信令的任何方式。

关键的是，信令服务器不需要理解 SDP 内容。它只是将一段文本从对等点 A 传递到对等点 B。SDP 对信令基础设施来说是"黑盒子"。

3. 对等点 B 接收并处理提供

对等点 B 通过信令通道接收提供并将其设置为远程描述（setRemoteDescription()）。浏览器解析 SDP 以了解对等点 A 的能力以及他们为通话提议的内容。

4. 对等点 B 创建应答

对等点 B 通过调用 createAnswer() 创建 SDP 应答。此应答通过以下方式响应提供：

从提供的编解码器中选择兼容的（拒绝不支持的）
确认接受哪些媒体流
提供自己的加密密钥
添加网络传输详情

5. 发送应答

对等点 B 将此应答设置为其本地描述并通过信令通道发送回对等点 A。对等点 A 接收它并将其设置为远程描述。

6. ICE 候选交换

在提供/应答交换发生的同时，双方对等点都在收集 ICE 候选——连接的潜在网络路径。每次对等点发现一个候选（本地 IP、来自 STUN 的公网 IP、来自 TURN 的中继地址）时，他们通过信令将其发送给对方。

这称为"涓流 ICE"——候选在发现时就发送，而不是等待所有候选后再发送。这显著加快了连接建立速度，通常将设置时间从 5-10 秒减少到 1 秒以内。

7. 建立连接

一旦双方对等点拥有彼此的 SDP 和足够的 ICE 候选，ICE 执行连接性检查并建立最佳的点对点路径。媒体开始在对等点之间直接流动，信令通道对媒体本身不再需要（尽管它通常保持可用以进行通话控制，如添加参与者或结束通话）。

什么是 SDP？

会话描述协议（Session Description Protocol，简称 SDP）是 WebRTC 提供和应答使用的格式。SDP 在 RFC 8866 中定义，是一种基于文本的协议，最初设计用于描述多媒体会话。虽然看起来神秘，但它是人类可读的，遵循简单的键=值格式。

SDP 消息包含：

会话级信息：会话名称、时间、连接数据
媒体描述：每种媒体类型一个（音频、视频、数据通道）
属性：编解码器详情、加密、ICE 参数、传输协议

每个媒体描述（m= 行）按优先级顺序列出编解码器。例如，m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 表示这是支持三种编解码器的视频流，ID 为 96、97 和 98（VP8、VP9、H.264 等，在后续 rtpmap 属性中指定）。

虽然你很少需要手动解析 SDP（浏览器处理它），但理解其结构有助于调试连接问题和优化编解码器选择。

常见信令协议

由于 WebRTC 没有标准化信令，开发者可以自由选择最适合其应用的方式：

WebSocket（最常见）

WebSocket 通过单个 TCP 连接提供全双工、实时、双向通信。它是 WebRTC 信令的事实标准，因为：

低延迟（持久连接，无重连开销）
高效的实时信令（从服务器立即推送到客户端）
Socket.IO、ws、uWebSockets 等库支持良好
自然适合涓流 ICE（在候选被发现时流式传输）

大多数生产级 WebRTC 应用使用 WebSocket 进行信令。

HTTP（REST + 轮询或 SSE）

基于 HTTP 的信令使用 REST API 发送消息，使用轮询或服务器推送事件（SSE）接收消息。虽然不如 WebSocket 高效，但它可以穿过可能阻止 WebSocket 的严格企业防火墙。

WHIP（WebRTC-HTTP 接入协议）和 WHEP（WebRTC-HTTP 输出协议）是使用简单 HTTP POST 请求进行信令的现代 IETF 标准，特别适用于广播场景。

自定义/专有协议

一些应用使用现有的消息基础设施：

XMPP/Jingle（扩展现有聊天协议的消息应用）
SIP（与传统 VoIP 基础设施集成）
MQTT（物联网应用）
自定义消息队列（RabbitMQ、Redis Pub/Sub）

信令服务器的角色

信令服务器通常处理：

用户在线状态：跟踪哪些用户在线并可进行通话
房间/会话管理：创建和管理通话房间，处理谁可以加入
消息路由：在对等点之间中继 SDP 提供、应答和 ICE 候选
身份验证：验证用户有权发起或加入通话
通话控制：协调静音/取消静音、添加参与者、屏幕共享、结束通话等事件

信令服务器也是实现业务逻辑的地方：用户权限、录制触发器、计费事件、分析等。虽然它不处理媒体，但它是整个视频通话系统的控制平面。

不同架构中的信令

点对点

在纯 P2P 中，信令服务器只帮助对等点找到彼此并交换初始连接数据。一旦连接，对等点直接通信。信令服务器可以在通话中途离线而不影响媒体质量。

SFU（选择性转发单元）

使用 SFU 时，信令变得更复杂。服务器必须协调：

每个客户端与 SFU 的连接（不是点对点）
每个参与者订阅哪些流
联播层选择
参与者改变视图时的动态流路由

SFU 信令比 P2P 更复杂，通常使用超越基本 SDP 交换的自定义协议。

MCU（多点控制单元）

MCU 信令在某些方面更简单——每个客户端连接到 MCU 服务器，接收一个合成流，信令服务器管理谁在会议中。MCU 在服务器端处理所有混合，因此信令专注于房间管理而不是复杂的流路由。

安全考虑

使用安全传输

始终使用 WSS（安全 WebSocket）或 HTTPS，而不是普通 WS 或 HTTP。SDP 包含加密指纹，但如果信令通道本身未加密，攻击者可以通过修改 SDP 执行中间人攻击。

验证信令消息

验证用户有权发送提供、加入房间或访问某些通话。实施基于令牌的身份验证（JWT 是常见的），并在每条信令消息上验证令牌，而不仅仅是初始连接。

速率限制

信令服务器容易受到 DoS 攻击。恶意客户端可能会用提供或加入请求轰炸服务器。对每个用户/IP 实施速率限制以防止滥用。

验证 SDP

虽然将 SDP 视为黑盒子，但你仍然可以验证基本合理性：大小限制（典型 SDP 为 2-10KB，任何巨大的都可疑）、正确格式、合理数量的媒体行。这可以防止试图利用 SDP 解析器的攻击。

调试信令问题

当 WebRTC 连接失败时，信令通常是罪魁祸首：

连接永远不启动：检查 SDP 提供/应答是否交换。使用浏览器开发者工具的网络标签验证信令消息到达
"设置远程描述失败"错误：SDP 格式错误或不兼容。检查编解码器协商，确保双方对等点至少支持一种通用编解码器
ICE 候选未到达：信令通道可能不支持涓流 ICE 消息，或候选中继逻辑存在错误
连接有时有效有时无效：信令中的竞态条件。确保正确顺序：setLocalDescription → 发送提供 → 接收应答 → setRemoteDescription

Chrome 的 chrome://webrtc-internals 显示完整的信令交换，包括 SDP 内容和时间，对调试非常宝贵。

现代发展（2025 年）

WHIP/WHEP

WebRTC-HTTP 接入协议（WHIP）和 WebRTC-HTTP 输出协议（WHEP）为广播用例标准化了基于 HTTP 的信令。它们将信令复杂性降低到简单的 HTTP POST 请求，非常适合将流接入到 CDN 或云服务。

2025 年采用率正在增长，特别是在传统 WebSocket 信令过于复杂的直播和广播场景中。

去中心化信令

一些项目探索使用 DHT（分布式哈希表）、区块链或对等发现协议的去中心化信令。虽然在理论上有趣，但对于 2025 年的生产应用来说，集中式信令服务器仍然更实用和可靠。

总结

信令是 WebRTC 的无名编舞者。虽然它不传输媒体，但它通过协调初始握手使整个点对点连接成为可能。理解信令对于调试 WebRTC 问题、实现安全的视频通话和扩展基础设施至关重要。

WebRTC 刻意不标准化信令是一种优势，而不是劣势。它允许你将 WebRTC 集成到任何现有系统中——无论你是为聊天应用添加视频、构建远程医疗平台还是创建游戏语音聊天功能。你可以重用现有的身份验证、消息基础设施和业务逻辑。

信令服务器是你应用独特身份所在的地方。WebRTC 连接可能是标准化的，但信令是你区分产品的地方。