6、信令机制：信令的作用、WebSocket实现信令、JSON消息格式、房间管理概念

聊到WebRTC，很多人第一反应是「点对点传输」、「音视频编解码」、「NAT穿透」这些硬核技术。但说实话，真正让WebRTC跑起来的，其实是信令。没有信令，两个浏览器就是两个孤岛，谁也找不到谁。

我个人习惯把信令比作「约会前的电话」。你想啊，两个人要见面，总得先打个电话约好时间地点吧？WebRTC里的信令干的就是这个活——帮两个Peer交换连接所需的信息。

信令到底在干什么？

说白了，信令就是用来交换三种信息的：

• 会话描述（SDP）：告诉对方「我支持什么编码、我的IP和端口是多少」
• 网络候选（ICE Candidate）：告诉对方「我有哪些可能的连接路径」
• 会话控制：比如「我要加入房间了」、「我要挂断了」

这里有个关键点——WebRTC标准并没有规定信令该怎么传。你可以用WebSocket、HTTP轮询、甚至用鸽子送信（只要你等得起）。但实际项目中，WebSocket是最主流的选择。

WebSocket实现信令——我踩过的坑

我在项目中第一次用WebSocket做信令时，犯过一个低级错误——忘了处理连接断开重连。用户网络闪断一下，信令通道就断了，整个通话直接挂掉。嗯，这里要注意：WebSocket的断线重连机制，一定要在信令层做。

一个典型的信令服务器实现，大概长这样：

// 信令服务器（Node.js + ws库）
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });

// 房间管理（内存版，生产环境请用Redis）
const rooms = new Map();

wss.on('connection', (ws) => {
  ws.on('message', (message) => {
    const data = JSON.parse(message);
    
    switch(data.type) {
      case 'join':
        handleJoin(ws, data.roomId);
        break;
      case 'offer':
        forwardToPeer(ws, data.targetId, data);
        break;
      case 'answer':
        forwardToPeer(ws, data.targetId, data);
        break;
      case 'ice-candidate':
        forwardToPeer(ws, data.targetId, data);
        break;
      case 'leave':
        handleLeave(ws, data.roomId);
        break;
    }
  });
});

你想想看，这个服务器其实很「傻」——它不关心消息内容，只负责转发。但就是这种简单的转发，构成了整个信令的骨架。

JSON消息格式——约定大于配置

信令消息用什么格式？我个人建议统一用JSON。为什么？因为前后端解析都方便，而且可读性强。调试的时候直接看消息内容，一目了然。

我一般会定义这样一套消息格式：

举个例子，一个offer消息长这样：

{
  "type": "offer",
  "roomId": "room-123",
  "senderId": "user-A",
  "targetId": "user-B",
  "payload": {
    "sdp": "v=0\r\no=- ...",
    "type": "offer"
  }
}

房间管理——别小看这个设计

房间管理听起来简单，不就是把几个人拉到一个组里吗？但实际做起来，坑不少。

我曾经遇到过一个场景：用户A创建房间，用户B加入，两人开始通话。然后用户A刷新了页面，房间还在，但用户A的WebSocket连接断了。这时候用户B还在等A的媒体流，结果等了个寂寞。

所以房间管理至少要处理这几个问题：

• 房间生命周期：最后一个用户离开时，房间是否自动销毁？
• 用户断线检测：WebSocket断开后，是立即移除用户，还是给个缓冲时间？
• 房间容量：一个房间最多能容纳多少人？一对一通话和多人会议的处理逻辑完全不同。
• 房间持久化：服务器重启后，房间信息还在吗？

下面这张图，是我个人总结的信令交互流程：

信令服务器的选型建议

如果你问我信令服务器用什么技术栈，我的回答是：选你最熟悉的。Node.js、Go、Java、Python都行。信令服务器的核心逻辑很简单，就是消息路由和房间管理，性能瓶颈通常不在语言本身，而在架构设计。

但有一点我特别想强调——信令服务器最好是无状态的。什么意思？就是房间信息不要存在内存里，而是存在Redis或者数据库里。这样即使服务器挂了，重启后房间信息还在，用户不会掉线。

好了，关于信令机制，核心就是这些。记住一句话：信令是WebRTC应用的骨架，骨架稳了，上层业务才能跑得顺畅。

公众号:蓝海资料掘金营，微信deep3321