websocket仅负责传输webrtc所需的信令数据（offer/answer/icecandidate），无法直接传输音视频流，因其基于tcp导致队头阻塞、无丢包恢复机制、缺乏nat穿透能力且浏览器不支持mediastream直接序列化。
WebSocket 本身不传输音视频，它只负责传递 WebRTC 建立连接所需的信令数据——offer、answer 和 icecandidate。想靠 WebSocket 单独实现音视频通话，不可能。
为什么不能直接用 WebSocket 传音视频流
WebSocket 是基于 TCP 的全双工文本/二进制通道，而 WebRTC 音视频流依赖 UDP 实现低延迟传输，并通过 DTLS/SRTP 加密、Jitter Buffer、NACK/PLI 重传等机制保障实时性。强行把原始音视频帧塞进 WebSocket，会遇到：
- TCP 队头阻塞导致卡顿严重，100ms 延迟直接变 800ms+
- 无内置丢包恢复，弱网下画面撕裂、声音断续无法缓解
- 没有 ICE 框架，NAT 穿透失败率极高（尤其在企业内网、校园网）
- 浏览器不支持将
MediaStream直接序列化为 WebSocket 可发的格式
RTCPeerConnection 必须配合 WebSocket 做信令交换
WebRTC 不自带信令机制，RTCPeerConnection 实例之间必须通过第三方通道交换三类关键信息：
-
offer和answer：描述本地支持的编解码器、传输能力、媒体轨道等，用 SDP 格式表达 -
icecandidate：候选地址（host/relay/relay），用于 NAT 穿透，每次收集到一个就需立即发送 -
iceconnectionstate变化通知（可选）：便于前端感知连接是否真正建立成功
WebSocket 是最常用、最轻量的信令载体，但注意：它只是“邮差”，不是“运输机”。示例中常见错误是漏发 icecandidate 或未监听 onicecandidate 事件：
peerConnection.onicecandidate = (event) => {
if (event.candidate) {
ws.send(JSON.stringify({ type: 'candidate', candidate: event.candidate })); // ✅ 必须带类型字段区分信令
}
};
信令消息结构必须约定清晰，否则双方无法解析
WebSocket 收发的每条消息都应有明确 type 字段，接收方按类型分发处理。常见缺失设计：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 混用字符串和 JSON：
ws.send("offer")vsws.send(JSON.stringify({type:"offer", sdp:...}))—— 后者才是可靠做法 - 忽略用户标识：没带
from/to字段，导致多人通话时信令错发给错误目标 - 未处理乱序：
candidate可能比offer先到，接收方需缓存并等待setRemoteDescription后再 add
最小可用结构示例：
{
"type": "offer",
"from": "userA",
"to": "userB",
"sdp": "v=0\r\no=- 123456 2 IN IP4 127.0.0.1\r\n..."
}
STUN/TURN 配置不当，90% 的连接失败源于此
RTCPeerConnection 的 iceServers 配置决定能否穿透 NAT。仅配 STUN（如 stun:stun.l.google.com:19302）在对称型 NAT 下必然失败；纯内网环境可能连 STUN 都不需要。实际部署必须：
- 至少配置一个公共 STUN（调试用） + 一个私有 TURN（生产必备）
- TURN 凭据需动态生成（不能硬编码），避免密钥泄露
- 检查
iceTransportPolicy：设为"all"（默认）才能尝试 host/relay 多种路径 - 监听
icegatheringstate：从"gathering"到"complete"才算候选收齐
常见错误写法：iceServers: [{ urls: "stun:..." }] —— 缺少 username 和 credential 字段，TURN 就会静默降级为 STUN。
真正容易被忽略的是：信令服务器不处理状态同步，比如用户 A 发起呼叫后掉线，B 端不会自动知道；ICE 连接建立后，getStats() 返回的网络质量指标（如 bytesReceived、packetsLost）需要主动上报，否则无法做自适应码率或 UI 提示。这些都不是 WebRTC 自动完成的。
