一、WebRTC 与信令服务器概述
说实话，我第一次接触 WebRTC 的时候，心里想的是：「这不就是浏览器里开个视频通话吗？能有多复杂？」
结果真动手做起来，才发现坑比想象中多得多。尤其是信令服务器这块，很多人一开始都忽略了它，觉得「不就是传个消息嘛」。嗯，等真正跑起来，你就知道它有多关键了。
1.1 什么是 WebRTC
WebRTC，全称是 Web Real-Time Communication。说白了，就是让浏览器之间能直接传音频、视频和数据，不需要装插件，不需要第三方软件。
我习惯把它理解成「浏览器里的对讲机」。你打开一个网页，就能跟另一个打开网页的人实时通话。听起来很酷对吧？
但这里有个关键点：WebRTC 是点对点的。也就是说，数据流是直接在两个浏览器之间传输的，不经过服务器中转。这样做的好处很明显——延迟低、带宽省、隐私好。
不过，问题也来了：
- 两个浏览器怎么找到对方？
- 它们怎么知道对方的网络地址？
- 如果都在内网里，怎么穿透 NAT？
- 用什么格式传数据？
这些问题，WebRTC 自己解决了一部分，但另一部分，就需要信令服务器来帮忙了。
核心要点：WebRTC 负责媒体数据的传输，但它不负责「如何建立连接」这件事。建立连接的过程，就是信令的职责。
1.2 为什么需要信令服务器
你想想看，两个人要视频通话，总得先知道对方在不在线、愿不愿意接、用什么方式接吧？
这些信息，WebRTC 本身不处理。它只负责「连接建立之后」的事。那「连接建立之前」的事谁来管？
——信令服务器。
我在项目中遇到过这样一个场景：两个用户都在公司内网，按理说内网之间通信应该很快。但第一次测试时，视频就是出不来。查了半天，发现是信令没传过去——因为信令服务器用的是 HTTP 短轮询，延迟太高，等 SDP 交换完，对方已经超时了。
所以你看，信令服务器看似简单，但它直接影响连接能否建立、建立得快不快。
信令服务器需要完成以下几件事：
- 会话控制：谁发起通话？谁接听？谁挂断？
- 媒体协商：交换 SDP（Session Description Protocol），告诉对方自己支持什么编码、什么分辨率。
- 网络协商：交换 ICE Candidate，帮助双方找到最优的网络路径。
- 用户管理：谁在线？谁离线？怎么通知对方？
我的建议：刚开始做信令服务器时，别想着一步到位。先用 WebSocket 传 JSON 消息，跑通流程再说。优化是后面的事。
1.3 信令服务器的核心职责
信令服务器的职责，其实可以归纳为三个字：搭桥。
它不参与媒体数据的传输，但它负责让两端的浏览器能「握手」成功。
具体来说，核心职责包括：
- 消息路由：把 A 的消息转发给 B，把 B 的消息转发给 A。就这么简单，但也最容易出错。
- 房间管理：多人通话时，谁在哪个房间？房间满了怎么办？谁来控制权限？
- 连接状态维护：用户断线了怎么办？重连后怎么恢复？
- SDP 与 ICE 交换：这是信令的核心数据，必须保证顺序、完整、不丢失。
我曾经踩过一个坑：ICE Candidate 的传输顺序很重要。如果先传了 SDP，再传 Candidate，没问题。但如果 Candidate 传得比 SDP 快，浏览器会直接丢弃——因为它还不知道对方的 SDP 是什么。
嗯，这个坑我花了半天才定位到。所以后来我习惯在信令服务器里加一个简单的队列，保证消息按序到达。
注意：信令服务器本身不处理媒体数据，所以它的性能压力通常不大。但它的可靠性要求很高——一旦信令丢失，连接就建立不起来。
1.4 信令与媒体的关系
很多人搞不清楚信令和媒体到底有什么区别。我画了一张图，帮你理清思路：
从这张图可以看得很清楚：信令服务器只在连接建立前起作用。一旦双方握手成功，媒体数据就走 P2P 通道了，信令服务器就不再参与。
这也是为什么信令服务器的压力通常不大——它只传控制消息，不传媒体数据。
1.5 信令服务器的技术选型
信令服务器用什么技术实现？这个问题我经常被问到。
我的回答是：用什么语言不重要，重要的是协议选对。
常见的方案有：
| 方案 | 协议 | 优点 | 缺点 |
|---|---|---|---|
| WebSocket | ws/wss | 全双工、低延迟、浏览器原生支持 | 需要自己处理重连、心跳 |
| HTTP 轮询 | http/https | 实现简单、兼容性好 | 延迟高、浪费带宽 |
| SSE | http | 单向推送、浏览器原生支持 | 只能服务器推，客户端不能发 |
| Socket.IO | ws+http | 自动重连、房间管理、事件机制 | 依赖库、协议非标准 |
我个人习惯用 WebSocket。原因很简单：它是标准协议，浏览器原生支持，而且双向通信，延迟低。
如果你不想自己造轮子，Socket.IO 也是个不错的选择。但要注意，它的协议不是标准的 WebSocket，如果以后要跟其他客户端互通，可能会有兼容性问题。
避坑指南：我曾经在生产环境中用过 HTTP 轮询做信令，结果用户一多，服务器 CPU 直接飙到 90%。后来换成 WebSocket，CPU 降到 10% 以下。所以，别图省事用轮询，除非你的用户量真的很少。
1.6 小结
这一章我们聊了 WebRTC 的基本概念、信令服务器的必要性，以及它的核心职责。
说白了，信令服务器就是那个「牵线搭桥」的角色。它不参与通话本身，但没有它，通话根本建立不起来。
下一章，我们会动手写一个最简单的信令服务器，用 Node.js + WebSocket 实现。到时候你会发现，核心代码其实没几行，但细节决定成败。
记住一句话：信令是 WebRTC 的「握手」，握不上手，后面的一切都是空谈。
公众号:蓝海资料掘金营，微信 deep3321