WebSocket仅用于传输WebRTC信令（如SDP、ICE候选者），不传音视频流；RTCPeerConnection负责实际媒体传输；需精简JSON格式、加seq序号、合并候选者、分离信令与媒体事件、服务端轻量透传。
WebSocket 本身不直接传输音视频流，而是专用于低延迟、双向、文本或二进制的信令（signaling）通信——比如交换 SDP、ICE 候选者、连接状态等控制信息。真正传输音视频的是 WebRTC 的 RTCPeerConnection，WebSocket 只负责“传话”。要实现低延迟的信令，关键不是 WebSocket 多快，而是如何用它把信令发得准、稳、及时。
用 WebSocket 建立可靠信令通道
WebSocket 比 HTTP 轮询或长连接更轻量，连接建立后无握手开销，适合频繁小消息交互。建议：
- 服务端选用支持高并发、低延迟的实现，如 Node.js +
ws库、Go 的gorilla/websocket，避免用 Express 默认中间件做信令路由（易阻塞） - 客户端创建时开启自动重连（带退避策略），例如 1s → 2s → 4s，防止短暂断网导致信令丢失
- 连接成功后立即发送
{"type": "register", "userId": "xxx"}类注册消息，服务端据此维护用户-连接映射，便于后续定向转发
信令消息设计要精简且带序号
低延迟不等于“越快越好”，而是“不丢、不乱、不积压”。推荐做法：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 所有信令统一用 JSON 格式，字段尽量扁平，避免嵌套深或冗余字段（例如不用
data.payload.sdp.type，直接用sdpType） - 为每条发出的消息加单调递增的
seq字段，接收方发现seq跳变可主动请求补发（适用于关键信令如 offer/answer） - 对 ICE 候选者这类可能批量到达的消息，允许合并发送（如 50ms 内攒批发一次），减少小包数量，但需设置最大延迟阈值（如 ≤100ms）
避免信令与媒体流互相干扰
WebSocket 连接和 RTCPeerConnection 是独立的，但逻辑上要协同。常见误区是把媒体事件（如 track 添加）也走 WebSocket 回传，这反而增加延迟和负担：
立即学习“Java免费学习笔记（深入）”；
- 只通过 WebSocket 传递 WebRTC 必需信令：offer、answer、candidate、bye、iceRestart
- 本地媒体状态（如 mute/unmute、track enabled）应直接操作
MediaStreamTrack，无需上报；远端状态变化由对方在 newtrack 或 onremovetrack 中处理 - 若需同步 UI 状态（如“对方正在说话”），可用极简心跳消息（
{"type":"speaking","on":true}），不走 SDP 流程
服务端要做轻量路由与快速透传
信令服务器不是业务服务器，核心职责是“收—判—转”，不能参与 SDP 解析或 ICE 处理：
- 收到消息后，仅根据
to字段或房间 ID 查找目标连接，原样转发（binary 数据保持 ArrayBuffer 不转 base64） - 禁用日志全量打印信令内容（尤其 candidate 含 IP，有隐私和性能风险），只记录连接生命周期和错误
- 对同一房间内广播类消息（如“有人加入”），用
for...of同步遍历连接并 send，不要用 Promise.all（失败一个会拖慢全部）
