📚 课程目录第3章信令服务器设计

3、信令服务器设计：信令协议选型（WebSocket/SIP）、信令服务器架构、房间管理逻辑实现

信令服务器，说白了就是 WebRTC 通话的「总调度室」。媒体流走的是 P2P 直连，但谁和谁连、什么时候连、连之前交换什么参数，这些都得靠信令来协调。

我在 ARM 设备上做多路通话时，踩过最大的坑就是信令设计不合理。一开始觉得信令嘛，传个 SDP 和 ICE 候选就行了，结果一上并发就崩。后来才明白——信令服务器的设计，直接决定了整个系统的稳定性和扩展性。

3.1 信令协议选型：WebSocket vs SIP

选协议之前，先想清楚你的场景。我见过不少团队一上来就上 SIP，觉得「专业」，结果开发周期翻倍。也见过只用 WebSocket 裸写的，后期想对接 SIP 中继时痛苦不堪。

对比维度	WebSocket	SIP (WebSocket 传输)
协议复杂度	低，自定义消息格式	高，RFC 3261 规范庞大
浏览器原生支持	原生 WebSocket API	需 sip.js 等库封装
与 PSTN 互通	需额外网关	原生支持，SIP trunk 直连
调试难度	低，JSON 明文可读	中，SIP 消息头多
ARM 设备资源消耗	低，单连接约 50KB 内存	中，协议栈开销大
扩展性	需自建路由逻辑	已有成熟路由机制

我的建议：纯浏览器端 WebRTC 场景，用 WebSocket 就够了。需要对接电话网络（PSTN）或已有 SIP 基础设施时，再上 SIP over WebSocket。

我个人习惯在 ARM 设备上跑信令服务时，选 WebSocket 方案。原因很简单——ARM 的 CPU 资源本来就紧张，SIP 协议栈的解析开销在并发高时会成为瓶颈。我在 RK3588 设备上压测过，同样 500 路并发，WebSocket 方案的 CPU 占用比 SIP 方案低约 35%。

3.2 信令消息协议设计

不管你选哪种传输层协议，应用层的消息格式都得自己定。我见过最糟糕的设计——把整个 SDP 原文当消息体传，连个类型字段都没有。解析的时候全靠正则匹配，维护起来想哭。

这里给出一套我打磨过的消息格式：

{
  "type": "join|leave|offer|answer|candidate|room_list|mute|unmute",
  "roomId": "room_001",
  "userId": "user_a",
  "payload": {
    // 根据 type 不同，payload 结构不同
  },
  "timestamp": 1700000000000,
  "seq": 1
}

为什么要加 seq 字段？嗯，这里要注意——WebSocket 虽然有序，但信令消息可能经过转发、重试，客户端收到乱序的情况我遇到过好几次。加个序列号，客户端可以自己排序或丢弃过期消息。

实战技巧：消息类型用字符串枚举，不要用数字。调试时看日志直接知道是什么消息，省去查表的功夫。我在生产环境吃过这个亏——数字 3 到底是 offer 还是 answer，不同版本居然定义不一样。

3.3 信令服务器架构

单机架构在 ARM 设备上能撑多久？我实测过，一台 RK3588 开发板，Node.js 写的信令服务，8 核 CPU，16GB 内存，纯 WebSocket 连接，大约能扛 2000 路并发。超过这个数，就得考虑分布式了。

下面这张图是我在项目中实际使用的架构：

这个架构的核心思路：无状态信令节点 + 有状态消息总线。每个信令节点只维护 WebSocket 连接，不存房间数据。房间信息全部放 Redis。这样节点挂了，客户端重连到其他节点，房间状态还在。

注意：ARM 设备做信令节点时，Redis 客户端连接数要控制。我遇到过 Redis 连接池耗尽导致信令超时的问题。建议每个信令节点限制 Redis 连接池大小为 CPU 核心数的 2 倍。

3.4 房间管理逻辑实现

房间管理是信令服务的核心。说白了就三件事：谁进来了、谁出去了、屋里现在有谁。

我设计房间数据结构时，用 Redis Hash 来存：

// 房间元数据
room:{roomId} -> Hash
  - name: "测试房间"
  - maxUsers: 8
  - createdBy: "user_a"
  - createdAt: 1700000000000
  - status: "active" | "closed"

// 房间成员列表
room:{roomId}:members -> Set
  - "user_a"
  - "user_b"
  - "user_c"

// 用户连接映射
user:{userId}:connection -> String
  - "ws://node1:8080/conn_abc123"

加入房间的流程，我习惯这么设计：

客户端发送 join 消息，携带 roomId 和 userId
服务端校验：房间是否存在、是否满员、用户是否已在房间
写入 Redis：将用户加入 room:{roomId}:members，记录 user:{userId}:connection
广播通知：通过消息队列通知房间内其他用户
返回当前成员列表：让新加入者知道屋里都有谁

避坑指南：我曾经在广播成员列表时，直接把整个 Set 发出去。结果一个房间 50 人，每次有人进出都发 50 条消息。后来改成增量更新——只发「谁加入了」或「谁离开了」，客户端自己维护列表。消息量从 O(n) 降到了 O(1)。

离开房间的逻辑要处理几种情况：

主动离开：客户端发 leave 消息，正常清理
WebSocket 断开：onclose 事件触发，被动清理
心跳超时：30 秒无心跳，强制踢出

我遇到过最头疼的问题——ARM 设备网络不稳定，频繁断连重连。每次重连都重新加入房间，Redis 里残留一堆僵尸连接。后来加了心跳机制，配合 TTL 自动过期：

// 用户在线状态，带 TTL
user:{userId}:online -> String "alive"
EXPIRE user:{userId}:online 60

// 心跳刷新
每隔 30 秒客户端发 ping
服务端收到后刷新 TTL

这样就算客户端突然掉线，60 秒后 Redis 自动清理，不用写复杂的清理逻辑。

3.5 多房间与频道隔离

实际项目中，房间往往需要分类。比如一个教育平台，有「数学课房间」、「英语课房间」，每个房间内可能还有「老师频道」和「学生频道」。

我的做法是用 房间 + 频道 两级隔离：

// 频道订阅
room:{roomId}:channel:{channelId} -> Set
  - "user_a"
  - "user_b"

// 消息路由时，只发给同频道的用户
// 老师发言 -> 所有学生能收到
// 学生提问 -> 只有老师和提问者能收到

这种设计在屏幕共享场景特别有用。共享屏幕的人单独在一个频道，其他人订阅观看频道。信令消息只路由到相关频道，不会干扰主通话。

核心原则：信令消息的广播范围越小越好。能发到频道就别发到房间，能发到个人就别发到频道。我在 ARM 设备上测试过，精确路由比全房间广播节省约 60% 的信令带宽。

3.6 信令服务器的 ARM 优化

ARM 设备上跑信令服务，有几个优化点值得注意：

事件驱动模型：Node.js 的异步 I/O 天然适合信令场景。每个连接只占少量内存，不阻塞
减少 JSON 解析：高频信令（如 ICE 候选）用二进制格式传输，我试过 MessagePack，体积减少 40%
连接复用：同一个用户的多路通话复用一条 WebSocket，用消息里的 roomId 区分
CPU 亲和性：在 8 核 ARM 上，把信令进程绑定到 4 个核心，其他核心留给媒体处理

我记得有一次在树莓派 4B 上做压力测试，没做任何优化，500 路并发 CPU 就飙到 90%。后来加了连接复用和二进制序列化，同样负载 CPU 降到 40%。优化前后差距就是这么大。

信令服务器设计这块，说白了就是「连接管理 + 消息路由 + 状态同步」。选对协议、搭好架构、管好房间，后面多路通话和屏幕共享的实现才能站得住脚。ARM 平台资源有限，每一步设计都要精打细算。