当前位置：首页 > news >正文

为什么 AI 实时语音更偏向 WebRTC？

news 2026/7/10 15:24:35

把 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});