WebRTC（Web Real-Time Communication，网页实时通信）是一套让两个浏览器或 App 直接建立音视频与数据通道的技术标准，目标只有一个：把“从说话到听见”的延迟压到几十毫秒级，同时尽量保住音质。
为什么实时语音不用 WebSocket
WebSocket 给人的印象是“实时”，但它通常跑在 TCP 上。TCP 的承诺是不丢、不重、按顺序，代价是：某个包丢了，后面的包必须排队等它重传。聊天框里晚 200 毫秒没人察觉；语音里这 200 毫秒正好是你要听的那个字，等它到了，对话已经进行到下一句。
打个比方：WebSocket 像挂号信，保证每封都送到、按顺序拆，丢一封就等重寄；WebRTC 像打电话，偶尔听漏半句没关系，重要的是“现在”这句得立刻听到。人耳能容忍一点失真，甚至自己补全，但极度不能容忍延迟和忽快忽慢。
它靠什么兜住抖动和丢包
- 跑在 UDP 上，用 RTP（Real-time Transport Protocol）封包。丢了不重传，而是靠 FEC（前向纠错）多发点冗余、NACK（选择性重传，只在还来得及的时候补）、PLC（丢包隐藏）用前后帧“猜”出缺的那一小段。
- 接收端有抖动缓冲（jitter buffer）：先攒一小会儿再平滑播放，用几毫秒延迟换不卡顿。
- 内置带宽估计与拥塞控制，网络变差时主动降码率，而不是让声音直接崩掉。
- 两端靠 ICE、STUN、TURN 做 NAT 穿透，打不通就走中继转发；音频常用 Opus 编码，通话前还会做回声消除、降噪、自动增益。
- 一个常见误会：WebRTC 不管“怎么约”。信令（signaling）走什么协议由你定，实践中往往就用 WebSocket 传 SDP 和 ICE 候选地址。两者不是二选一，而是分工。
| 维度 | WebSocket(通常基于 TCP) | WebRTC |
|---|---|---|
| 传输层 | TCP | UDP 为主 |
| 丢包时 | 重传、按序等待，延迟尖峰 | 不重传，用冗余和隐藏兜 |
| 优化目标 | 平均延迟与可靠送达 | 延迟长尾与抖动 |
| 典型场景 | 文字消息、通知、信令 | 语音、视频、屏幕共享、低延迟数据通道 |
| NAT 穿透 | 不需要 | ICE + STUN/TURN |
对从业者和普通人的意义
做产品的：只要涉及麦克风、连麦、实时对讲或 AI 语音助手，选 WebRTC 或基于它的实时音频服务，别用 WebSocket 一帧帧推音频。后者平时也能跑，一到弱网就会延迟越积越多或“卡成机器人”——那不是 bug，是 TCP 在忠实履行承诺。做实时语音 Agent 的，WebRTC 负责“最后一公里”，打断检测、模型推理都要对齐它的时间轴，链路本身抖动太大，模型再快也救不回来。
普通用户：视频会议里对方声音变机器人、画面糊成马赛克，多半是它在降码率；声音断续但很快恢复，是丢包隐藏在工作。具体某款软件怎么做，以官方说明为准。