WebSocket是WebRTC信令传输的主流选择，因其提供持久、全双工、低延迟的TCP通道，专用于交换SDP、ICE候选等控制信息，不传输音视频流；WebRTC本身不定义信令机制，必须依赖外部通道完成连接协商。
WebSocket 是实现实时多人视频会议中信令传输的主流选择，它不传输音视频流本身，而是承担连接建立前后的“协调工作”——交换 SDP 描述、ICE 候选、状态通知等控制信息。
为什么必须用 WebSocket 做信令
WebRTC 本身不定义信令机制，它只提供连接能力（RTCPeerConnection），但不知道“跟谁连”“怎么连”。这就需要一个独立通道来传递协商参数。HTTP 轮询效率低、延迟高；而 WebSocket 提供持久、全双工、低开销的 TCP 连接，正好满足信令的实时性与可靠性要求。
- 信令消息体积小（通常几百字节），对带宽要求低，但对送达及时性敏感
- 一次连接建立后，双方可随时收发 offer/answer/ice-candidate，无需反复握手
- 服务端可通过 WebSocket 精确广播或定向转发，支撑房间管理、用户加入/离开通知等业务逻辑
信令流程中 WebSocket 的具体作用
在多人会议中，WebSocket 不只是点对点传消息，更是中心化协调枢纽：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 新用户加入时，前端通过 WebSocket 向服务端发送 join 请求，服务端分配房间 ID 并记录在线状态
- 发起方生成 SDP offer，经 WebSocket 发送给服务端，再由服务端广播给当前房间所有其他成员
- 每个成员收到 offer 后生成 answer，并通过 WebSocket 回传给发起方；同时各自收集 ICE 候选，持续通过 WebSocket 上报并分发
- 连接状态变化（如 ICE 连接断开）也通过 WebSocket 实时上报，便于前端做重连或降级提示
实际部署中的关键细节
单纯用 WebSocket 接口还不够，需结合业务逻辑做健壮设计：
- 每条消息应带 type 字段（如 "offer"、"answer"、"candidate"、"leave"），便于前后端统一解析
- 服务端需维护房间映射表和用户连接关系，避免消息错发或漏发；建议使用 Redis 存储在线状态和房间元数据
- 为防止单点故障，WebSocket 服务应支持集群部署，并通过消息队列（如 Kafka）或 Redis Pub/Sub 同步跨节点信令
- 生产环境务必启用 WSS（WebSocket Secure），配合 TLS 加密，防止信令被中间人窃听或篡改
它和 WebRTC 媒体流的关系
WebSocket 和 WebRTC 是分工明确的“搭档”：前者跑在 TCP 上，稳而慢，只管“说话”；后者跑在 UDP 上，快而尽力，专管“传画面和声音”。两者互不替代，也不重叠——音视频流永远不经过 WebSocket，它只负责把“怎么连”这件事说清楚。
