websocket不能直接传输实时语音，必须与webrtc分工协作：前者仅负责信令（sdp/ice/状态同步），后者专司低延迟媒体传输；强行用websocket传音频会导致延迟飙升、卡顿和崩溃。
WebSocket本身不能直接实现低延迟、全双工的实时语音传输，强行用它传原始音频帧会导致卡顿、延迟飙升甚至连接崩溃。真正可行的方案是：用 WebSocket 做信令，WebRTC 做媒体传输——这不是权衡取舍，而是技术分工的必然选择。
为什么不能只用 WebSocket 传语音流
常见错误现象：WebSocket 连接在传输 Opus 编码音频时突然断开、onerror 频发、浏览器内存持续上涨、语音出现明显“拖尾”或 2 秒以上延迟。
根本原因在于协议层冲突：
- TCP 的重传机制和队头阻塞（head-of-line blocking）会让一个丢包拖住后续所有音频帧，实时性彻底失效
- WebSocket 没有内置的抖动缓冲、丢包隐藏、动态码率适配等语音传输必需能力
- 浏览器对
WebSocket.send()的调用频率和数据块大小敏感，频繁小包发送易触发拥塞控制退避
即使你用 Opus 编码 + 分片 + ArrayBuffer 发送，也绕不开 UDP 才具备的“尽力而为”语义。这不是优化问题，是协议选型错误。
WebRTC 必须配合 WebSocket 的三个刚性场景
WebRTC 自身不解决连接初始化问题，以下环节必须依赖外部信令通道：
-
createOffer()生成的 SDP offer 必须通过WebSocket发给对方，否则对方无法知道你的编解码能力、媒体方向、DTLS fingerprint -
RTCPeerConnection收集到的ICE candidate（如candidate:udp:123.45.67.89 54321 typ host）需实时中转，缺一条就可能无法穿透 NAT - 通话状态同步（如
callInvite、callAccept、callHangup）必须可靠送达，WebSocket 的有序交付特性比 UDP 自建信令更稳
注意：WebSocket 在这里只传 JSON 或字符串，不碰二进制音视频帧；所有媒体流都走 WebRTC 自建的 RTCPeerConnection，完全绕过服务器带宽瓶颈。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
WebSocket 与 WebRTC 协同时的关键参数对齐
信令消息格式错位是调试中最常踩的坑。必须确保两端解析逻辑一致：
- SDP 中的
media行（m=audio 54321 RTP/AVP 111）要和RTCPeerConnection创建时传入的constraints匹配，否则setRemoteDescription()会静默失败 -
ICE candidate字符串必须原样透传，不能被 JSON 序列化/反序列化破坏换行或空格（建议用JSON.stringify(candidate)而非直接拼接） - 信令消息加
type字段（如{"type":"webrtcOffer","sdp":"..."}），避免_handleSocketMessage()里漏判类型导致流程中断
示例错误写法：ws.send(JSON.stringify({sdp: offer.sdp})) —— 缺少 type，接收方无法路由到 _onCalleeReceivedOffer()。
当 WebRTC 穿透失败时，WebSocket 可作为保底媒体中继
这不是推荐做法，但工业场景中真实存在：内网设备无法直连、防火墙禁 UDP、或需要集中录音审计时，可启用媒体中继模式。
此时架构变为：
- 客户端仍用
getUserMedia()采集音频，但不走RTCPeerConnection - 音频帧经
Opus编码后，通过WebSocket推送到服务器（注意：必须加timestamp和sequence number） - 服务端做简单混音/转发，并用另一路
WebSocket推给远端；远端按时间戳重排、播放
性能代价明显：端到端延迟从 200ms 升至 800ms+，且服务器 CPU 和带宽压力陡增。仅在 WebRTC P2P 确实不可用时启用，切勿默认开启。
最易被忽略的一点：WebRTC 的 RTCPeerConnection 实例必须在收到第一个 ICE candidate 前完成 setLocalDescription(offer)，否则候选地址无法绑定到连接。这个时序依赖靠 WebSocket 消息顺序保障，但实际网络中可能乱序——所以接收方一定要做 candidate 缓存，等 setRemoteDescription() 成功后再批量添加。
