信令服务器基础：信令的作用、WebSocket简介、搭建一个简单的Node.js信令服务器

好，咱们今天来聊聊信令服务器。说实话，很多刚接触WebRTC的朋友，一上来就被「信令」这两个字给唬住了。我当年也是，觉得这东西高深莫测。其实说白了，信令就是「让两个浏览器互相找到对方」的那套流程。

你想想看，WebRTC虽然能直接在浏览器之间传数据，但它有个前提——双方得先知道对方在哪。就像你要给朋友寄快递，总得先知道人家的地址吧？信令服务器干的就是这个活。

信令到底在做什么？

咱们先拆解一下信令的核心任务。我习惯把它分成三步：

  1. 交换会话描述（SDP）——告诉对方「我能接收什么格式的数据」
  2. 交换网络信息（ICE候选）——告诉对方「我当前的网络地址是什么」
  3. 协调连接建立——确保双方在同一个频道上对话

这里有个关键点：信令协议不是WebRTC标准的一部分。什么意思？就是你可以用任何方式传这些信息——WebSocket、HTTP轮询、甚至用鸽子送信都行。我个人习惯用WebSocket，因为它实时性好，而且双向通信很方便。

重要提醒：信令服务器只负责「转发」信息，它不参与媒体数据的传输。数据一旦建立连接，就直接走P2P通道了。信令服务器可以随时下线，只要连接已经建立，双方照样能通信。

WebSocket：信令的黄金搭档

为什么选WebSocket？我刚开始做WebRTC项目时，试过用HTTP长轮询。结果呢？延迟高不说，代码还写得特别别扭。后来换成WebSocket，整个世界都清净了。

WebSocket有几个特点，简直就是为信令量身定做的：

  • 全双工通信——服务器和客户端可以随时互发消息
  • 低延迟——建立连接后，没有HTTP的握手开销
  • 轻量级——头部开销只有2字节，比HTTP小得多

嗯，这里要注意：WebSocket本身不保证消息的可靠性。如果你需要确保每条信令都送达，得自己在应用层做ACK确认。我在一个视频会议项目里就吃过这个亏——丢了一条SDP，结果对方一直黑屏，排查了半天才发现是信令丢了。

搭建一个简单的Node.js信令服务器

好，咱们动手写代码。我会用Node.js + ws库，搭建一个最简版本的信令服务器。这个服务器只做三件事：接收消息、转发消息、管理房间。

先安装依赖：

npm init -y
npm install ws uuid

然后写服务器代码。我习惯把逻辑拆成两部分：连接管理和消息路由。

// server.js
const WebSocket = require('ws');
const { v4: uuidv4 } = require('uuid');

const wss = new WebSocket.Server({ port: 8080 });

// 存储所有房间信息
const rooms = new Map();

wss.on('connection', (ws) => {
  const clientId = uuidv4();
  console.log(`客户端 ${clientId} 已连接`);

  ws.on('message', (message) => {
    const data = JSON.parse(message);
    
    switch(data.type) {
      case 'join':
        handleJoin(ws, clientId, data.roomId);
        break;
      case 'offer':
      case 'answer':
      case 'ice-candidate':
        forwardMessage(ws, data);
        break;
      default:
        console.log('未知消息类型:', data.type);
    }
  });

  ws.on('close', () => {
    handleDisconnect(clientId);
  });
});

function handleJoin(ws, clientId, roomId) {
  if (!rooms.has(roomId)) {
    rooms.set(roomId, new Map());
  }
  
  const room = rooms.get(roomId);
  room.set(clientId, ws);
  
  // 通知房间内其他用户
  room.forEach((client, id) => {
    if (id !== clientId) {
      client.send(JSON.stringify({
        type: 'peer-joined',
        peerId: clientId
      }));
    }
  });
  
  console.log(`客户端 ${clientId} 加入房间 ${roomId}`);
}

function forwardMessage(ws, data) {
  // 找到目标客户端并转发消息
  const room = findRoomByClient(ws);
  if (room && room.has(data.targetId)) {
    const target = room.get(data.targetId);
    target.send(JSON.stringify(data));
  }
}

function handleDisconnect(clientId) {
  // 清理断开的客户端
  rooms.forEach((room, roomId) => {
    if (room.has(clientId)) {
      room.delete(clientId);
      // 通知房间内其他用户
      room.forEach((client) => {
        client.send(JSON.stringify({
          type: 'peer-left',
          peerId: clientId
        }));
      });
      
      if (room.size === 0) {
        rooms.delete(roomId);
      }
    }
  });
}

function findRoomByClient(ws) {
  for (const [roomId, room] of rooms) {
    for (const [clientId, client] of room) {
      if (client === ws) return room;
    }
  }
  return null;
}

console.log('信令服务器已启动，监听端口 8080');

小技巧：我在实际项目中，会给每条消息加一个序列号。这样接收方可以检测到消息是否丢失，如果发现丢包，可以主动请求重传。对于视频通话这种场景，丢一条ICE候选可能问题不大，但丢一条SDP就麻烦了。

客户端怎么用？

客户端代码更简单。你只需要创建一个WebSocket连接，然后按照约定的格式发送消息就行。

// 客户端示例
const ws = new WebSocket('ws://localhost:8080');

ws.onopen = () => {
  // 加入房间
  ws.send(JSON.stringify({
    type: 'join',
    roomId: 'my-room-123'
  }));
};

ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  
  switch(data.type) {
    case 'peer-joined':
      console.log('有新人加入:', data.peerId);
      // 这里可以开始创建PeerConnection
      break;
    case 'offer':
      // 处理收到的offer
      break;
    case 'answer':
      // 处理收到的answer
      break;
    case 'ice-candidate':
      // 添加ICE候选
      break;
  }
};

// 发送信令消息
function sendSignal(targetId, signalType, payload) {
  ws.send(JSON.stringify({
    type: signalType,
    targetId: targetId,
    payload: payload
  }));
}

避坑指南：我曾经在生产环境遇到过一个问题——客户端频繁重连导致服务器内存暴涨。原因是每次重连都会创建新的WebSocket对象，但旧的连接没有及时清理。后来我加了一个心跳机制，每30秒检测一次连接是否存活，不活跃的连接直接关闭。这个习惯我一直保留到现在。

信令流程全景图

下面这张图展示了完整的信令交互流程。你可以看到，信令服务器就像一个「中间人」，帮两个浏览器交换建立连接所需的信息。

信令交互流程 浏览器 A 信令服务器 浏览器 B ① 加入房间 ② 通知有新用户 创建 Offer (SDP) ③ 转发 Offer ④ 转发 Offer 创建 Answer (SDP) ⑤ 转发 Answer ⑥ 转发 Answer ICE 候选交换 ICE 候选交换 ⑦ 双向交换 ICE 候选 ⑧ P2P 连接建立，信令服务器退出

你看，信令服务器只在连接建立阶段活跃。一旦双方交换完必要的信息，它就可以「功成身退」了。这也是WebRTC设计的精妙之处——信令服务器不需要很高的带宽，因为它只传控制信息，不传媒体数据。

关于消息格式的一点建议

我见过很多团队在信令消息格式上踩坑。有人用XML，有人用自定义二进制格式。我个人建议统一用JSON，原因有三：

  • 可读性强——调试的时候一眼就能看出问题
  • 扩展性好——加字段不影响现有逻辑
  • 生态成熟——几乎所有语言都有现成的解析库

消息结构我习惯这样设计：

{
  "type": "offer | answer | ice-candidate | join | leave",
  "roomId": "房间标识",
  "senderId": "发送者ID",
  "targetId": "接收者ID（可选，广播时省略）",
  "payload": {
    // 具体的信令数据
  },
  "timestamp": 1234567890,
  "seq": 1  // 消息序列号，用于检测丢包
}

小提示：记得给每条消息加时间戳。我在排查线上问题时，经常靠时间戳来还原事件顺序。有一次两个客户端同时发offer，就是因为时间戳帮我定位到了竞态条件。

好了，信令服务器的基础就聊到这里。你只要记住：信令不传数据，只传「如何建立连接」的指令。WebSocket是当前最主流的信令传输方式，而Node.js加上ws库，十几行代码就能搭一个可用的信令服务器。动手试试看，你会发现这东西比想象中简单得多。

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

← 上一章 📖 返回目录 下一章 →