信令服务器设计：WebRTC 的“幕后指挥官”

聊到 WebRTC，很多人第一反应是 P2P、音视频、低延迟。但真正动手做过的人都知道——没有信令服务器，WebRTC 根本跑不起来。

我刚开始接触 WebRTC 时，也犯过这个错误。以为两端只要拿到对方的 IP 就能直接连。结果呢？两端都在内网，谁也找不到谁。后来我才明白，信令服务器才是整个通话的“幕后指挥官”。它不负责传音视频，但它负责让两端“认识彼此”。

信令到底在传什么？

信令消息其实不复杂。我把它归纳为三类：

• 会话控制消息：比如“发起通话”、“挂断”、“拒绝”。这些是业务层面的指令。
• SDP 交换：两端需要知道对方支持什么编码、用什么端口、网络拓扑如何。这些信息封装在 SDP 里。
• ICE Candidate 交换：每个候选地址（本机 IP、STUN 反射地址、TURN 中继地址）都需要通过信令传给对方。

你想想看，如果没有信令，A 端连 B 端在哪都不知道，怎么建连接？

为什么我选 WebSocket？

信令传输的协议选择很多。HTTP 轮询、长轮询、WebSocket、甚至直接 UDP 都有人用。但我个人习惯用 WebSocket。原因很简单：

协议	优点	缺点
HTTP 轮询	实现简单，兼容性好	延迟高，浪费带宽
长轮询	比轮询好一点	仍然有延迟，服务器资源消耗大
WebSocket	全双工、低延迟、浏览器原生支持	需要处理心跳和重连
原始 UDP	延迟最低	浏览器不支持，需要插件或自定义客户端

我在项目中遇到过用 HTTP 轮询做信令的案例。当时用户量一上来，服务器压力巨大，而且消息延迟导致 ICE 协商超时。后来换成 WebSocket，问题迎刃而解。说白了，WebRTC 本身就是实时通信，信令通道也应该是实时的。

信令消息格式怎么设计？

消息格式没有标准答案。但我建议用 JSON，简单、可读、扩展性好。下面是我常用的格式：

{
  "type": "offer",          // 消息类型
  "from": "user_a",         // 发送者
  "to": "user_b",           // 接收者
  "room": "room_123",       // 房间 ID
  "payload": {              // 具体数据
    "sdp": "v=0\r\no=...",
    "ice": [
      {"candidate": "...", "sdpMid": "0"}
    ]
  },
  "timestamp": 1700000000   // 时间戳，可选
}

消息类型我一般定义这么几种：

• join / leave：加入/离开房间
• offer / answer：SDP 交换
• ice_candidate：ICE 候选地址
• hangup：挂断
• error：错误通知

嗯，这里要注意一点：payload 字段不要塞太多无关数据。信令消息越轻量越好，毕竟它直接影响建连速度。

信令服务器实现示例

我用 Node.js + ws 库写一个最简版本。别小看它，核心逻辑都在里面了。

const WebSocket = require('ws');
const server = new WebSocket.Server({ port: 8080 });

// 房间管理：roomId -> Set<ws>
const rooms = new Map();

server.on('connection', (ws) => {
  let currentRoom = null;
  let userId = null;

  ws.on('message', (data) => {
    const msg = JSON.parse(data);

    switch (msg.type) {
      case 'join':
        // 加入房间
        currentRoom = msg.room;
        userId = msg.from;
        if (!rooms.has(currentRoom)) {
          rooms.set(currentRoom, new Set());
        }
        rooms.get(currentRoom).add(ws);
        // 通知房间内其他用户
        broadcast(currentRoom, {
          type: 'user_joined',
          from: userId
        }, ws);
        break;

      case 'offer':
      case 'answer':
      case 'ice_candidate':
        // 转发给目标用户
        forward(msg.to, msg);
        break;

      case 'leave':
      case 'hangup':
        // 离开房间
        if (currentRoom) {
          rooms.get(currentRoom)?.delete(ws);
          broadcast(currentRoom, {
            type: 'user_left',
            from: userId
          }, ws);
        }
        break;
    }
  });

  ws.on('close', () => {
    // 清理
    if (currentRoom) {
      rooms.get(currentRoom)?.delete(ws);
      broadcast(currentRoom, {
        type: 'user_left',
        from: userId
      }, ws);
    }
  });
});

// 广播给房间内其他人
function broadcast(room, msg, excludeWs) {
  const clients = rooms.get(room);
  if (!clients) return;
  clients.forEach(client => {
    if (client !== excludeWs && client.readyState === WebSocket.OPEN) {
      client.send(JSON.stringify(msg));
    }
  });
}

// 转发给指定用户
function forward(targetUserId, msg) {
  // 这里需要维护 userId -> ws 的映射
  // 实际项目中可以用 Map 存起来
  // 简化起见，这里只做示意
  console.log(`Forward to ${targetUserId}:`, msg);
}

信令交互流程

为了让你更直观地理解，我画了一张流程图。它展示了两个用户通过信令服务器建立 WebRTC 连接的完整过程。

你看，整个流程其实就三步：加入房间 → 交换 SDP → 交换 ICE Candidate。信令服务器只负责转发，不参与媒体数据的传输。这也是 WebRTC 的精髓——信令通道和媒体通道分离。

避坑指南

最后分享几个我踩过的坑：

• 不要用同一个 WebSocket 连接传媒体数据。信令和媒体必须分离。信令走 WebSocket，媒体走 RTP/RTCP。
• SDP 里不要写死 IP。我见过有人把本机内网 IP 写进 SDP，结果对方在外网根本连不上。用 ICE 框架自动协商就好。
• 信令服务器要支持多房间。别只写死一个房间。用 Map 管理房间列表，每个房间独立维护连接池。
• 消息顺序很重要。ICE Candidate 可能在 SDP 之前到达。客户端要做好缓存，等 SDP 到了再处理。

信令服务器看似简单，但它是整个 WebRTC 系统的“粘合剂”。设计得好，后续的 NAT 穿透、ICE 协商都会顺畅很多。下一节我们深入聊聊 ICE 框架——那才是真正头疼的部分。

---