把 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 谁更强”，而是问：你传的是消息，还是实时媒体？