把 WebRTC 和 WebSocket 的区别讲透
很多人一听到“实时通信”，第一反应就是 WebSocket。做文本聊天、直播弹幕、状态同步，它确实好用。但到了 AI 实时语音、视频通话、低延迟音频交互，WebRTC 往往更合适。原因不是简单一句“WebRTC 支持 P2P”，而是它在媒体传输、网络抖动、丢包处理和音频处理上，天生就是为实时场景设计的。
一、二者不是替代关系
WebSocket 更像一条长期在线的“消息通道”：浏览器和服务器之间可以持续收发消息，非常适合 JSON、文本、业务事件、状态变更。
WebRTC 更像一套“实时媒体系统”：它不仅能传数据，还负责麦克风、摄像头、音视频编解码、网络协商、抖动处理、加密传输等一整套能力。
WebSocket 解决“客户端和服务器怎么持续发消息”；WebRTC 解决“音频、视频和低延迟数据怎么稳定实时传”。
二、为什么 AI 实时语音更怕延迟，而不是更怕丢包？
文本消息必须完整。少一个字、丢一段 JSON，业务就可能出错，所以 WebSocket 背后的可靠有序传输很适合这类场景。
但语音不一样。一次通话里，20 毫秒前的声音如果迟迟补不回来，它已经失去价值。用户真正敏感的是“卡顿、停顿、延迟堆积”，不是某个瞬间音质有一点点损失。
这就是实时媒体和普通消息最大的区别：普通消息要完整；实时语音要及时。
三、WebSocket：适合可靠消息，不适合重度实时音频
WebSocket 的优势很直接：连接简单、兼容性好、服务端开发成熟。浏览器建立连接后，双方可以一直互相发消息，不需要反复发起 HTTP 请求。
在 AI 应用里，WebSocket 很适合这些场景：
文本大模型的 token 流式输出。
工具调用事件、任务状态、转写文本、日志推送。
浏览器到业务服务器之间的控制消息。
服务端到服务端的实时 API 对接。
一个最小化的 WebSocket 示例大概是这样：
const ws=new WebSocket("wss://example.com/realtime");ws.onopen=()=>{ws.send(JSON.stringify({type:"input_text", text:"你好，帮我总结今天的会议"}));};ws.onmessage=(event)=>{const message=JSON.parse(event.data);console.log("收到服务端消息：", message);};ws.onclose=()=>{console.log("连接已关闭");};但如果把连续音频也全部封装成 JSON 或二进制块走 WebSocket，就要自己处理音频采集、切片、缓冲、重传影响、播放同步、网络抖动、回声消除等一堆问题。能做，但成本高，而且延迟容易失控。
四、WebRTC：不是只会 P2P，而是内置实时媒体能力
WebRTC 的复杂度比 WebSocket 高很多。它不是简单连上服务器就完事，而是先交换 SDP，协商双方能支持什么音视频格式；再通过 ICE 收集候选地址，尝试直连；如果直连失败，再通过 TURN 中继。
这套流程看起来麻烦，但它帮我们解决了实时音视频里最麻烦的事情：跨 NAT、跨防火墙、弱网下媒体传输、加密和低延迟播放。
一个极简 WebRTC 浏览器端骨架如下：
const pc=new RTCPeerConnection({iceServers:[{urls:"stun:stun.l.google.com:19302"}]});const stream=await navigator.mediaDevices.getUserMedia({audio: true, video:false});stream.getTracks().forEach((track)=>{ pc.addTrack(track,stream);});const dataChannel=pc.createDataChannel("events");dataChannel.onmessage=(event)=>{ console.log("收到事件：",JSON.parse(event.data));};const offer=await pc.createOffer();await pc.setLocalDescription(offer);await signaling.send({type:"offer", sdp: offer.sdp});注意这里的 signaling 只是示意。真实项目里，信令可以用 HTTP，也可以用 WebSocket。WebRTC 标准本身并不规定信令怎么实现。
五、放到 AI 实时语音里，差异会被放大
AI 实时语音不是“发一段录音，等模型返回一段音频”这么简单。用户说话时，系统要持续采集麦克风；模型要边听边转写，边判断用户是否说完，边生成回复；如果用户打断，还要立刻停止播放旧回复。
这类体验里，WebRTC 更合适，因为它把音频流、播放、弱网适配和实时事件放到一套更贴近媒体场景的链路中。WebSocket 仍然有价值，但更适合后端对接、业务事件、服务端推送，而不是承担整个浏览器端语音媒体链路。
通俗点说：WebSocket 像打字聊天，WebRTC 像打电话。AI 实时语音更像打电话，而不是发消息。
六、对比表：不要死记，按场景看
很多争论来自一句话：“WebSocket 也能实时啊，为什么不用？”答案是：可以用，但要看实时到什么程度。
如果只是文本消息，WebSocket 足够好；如果是语音、视频、屏幕共享，WebRTC 的媒体能力更完整；如果是复杂 AI 产品，两者经常一起用。
七、真正的工程选型：不是选一个打死另一个
可以按下面这套规则选：
文本、JSON、控制事件：优先 WebSocket。
浏览器实时语音、视频、屏幕共享：优先 WebRTC。
服务端到服务端的实时 API 对接：WebSocket 更简单。
浏览器语音助手：WebRTC 传音频，WebSocket 或 DataChannel 传业务事件。
多人会议、多人连麦：通常还要引入 SFU，而不是靠浏览器全互联。
八、上线时最容易出问题的地方
WebSocket 的坑通常在连接管理：断线重连、心跳、鉴权、消息堆积、连接数、网关超时。
WebRTC 的坑通常在网络和媒体：ICE 失败、TURN 中继成本、设备权限、回声消除、丢包率、jitter、RTT、音频播放打断。它的调试成本更高，但换来的是更完整的实时媒体体验。
如果做 AI 实时语音，建议重点监控：端到端延迟、首包时间、音频丢包率、jitter、断连率、重连成功率、TURN 占比、用户打断成功率。
九、最后总结
WebSocket 和 WebRTC 都是实时通信技术，但它们的强项不同。WebSocket 更适合稳定、可靠、简单的消息通道；WebRTC 更适合低延迟、强互动、音视频密集的实时媒体场景。
在 AI 应用里，如果是文本聊天，WebSocket 很舒服；如果是实时语音助手，WebRTC 更接近用户期待的“电话级体验”；如果系统复杂，两者可以组合使用：WebRTC 负责媒体，WebSocket 负责信令、工具事件和业务状态。
最终不是问“WebRTC 和 WebSocket 谁更强”，而是问：你传的是消息，还是实时媒体？