3.实时传输：WebRTC 与 WebSocket 的选择
开发者导读
在构建 对话式 AI 时，首要的工程决策不是模型，而是通信。 “我该用 WebSocket 还是 WebRTC？” 这是几乎每个开发者都会问的问题。 WebSocket 简单易上手，是原型阶段的常用方案；WebRTC 则是更完整的实时媒体协议栈。 然而，随着应用从“能跑”到“能用”，从 Demo 到生产，这两者的差距会不断放大。
本章的目标，是帮助你理解：
WebSocket 与 WebRTC 在设计目标上的根本差异；
为什么 WebSocket 无法支撑实时语音体验；
WebRTC 如何在协议层就解决了延迟、打断、噪声与监控问题；
以及在 对话式 AI 中，选择 WebRTC 并不是“更复杂的方案”，而是“更省力的方案”。
3.1 开发者常见误区：为什么很多人最初会选 WebSocket
很多 对话式 AI 项目的起步阶段，团队通常希望“先跑起来”。
此时 WebSocket 是最快能拿出结果的方案：协议直观、实现简单、无需复杂配置。浏览器或 App 把音频帧打包，通过二进制形式发送到后端，后端再返回合成音频流，一个 Demo 就能工作，看起来实时、双向、方便。
问题在于，这种简易方案隐藏了大量技术债。
随着用户规模扩大、网络环境变复杂、设备差异变多，延迟、卡顿、打断无效、音频破裂、丢帧不明等问题会逐渐暴露。你会发现：WebSocket 能“传声音”，但没法“处理语音交互”。很多团队最终被迫重写传输层，从可靠字节流转向专门的媒体协议栈。
3.2 WebSocket 与 WebRTC：设计目标的根本不同
| 维度 | WebSocket | WebRTC |
|---|---|---|
| 传输协议 | TCP | UDP（SRTP） |
| 目标场景 | 实时数据、消息推送 | 实时音视频通信 |
| 延迟策略 | 保证可靠性，容忍延迟 | 优先低延迟，容忍丢包 |
| 媒体处理 | 无，需要自行实现 | 内建音频处理（AEC/ANS/AGC） |
| 拥塞控制 | 无，需应用层实现 | 内置拥塞控制与码率自适应 |
| NAT 穿透 | 不支持 | 支持 STUN/TURN |
| 监控与统计 | 无 | 内置 getStats API |
WebSocket 和 WebRTC 并非同类竞争者。
它们诞生时的设计目标完全不同：
WebSocket 是可靠的数据通道。
基于 TCP 协议，强调消息顺序与完整性。
它适合文本、状态、事件流等场景，如实时监控、游戏状态同步、消息推送等。
WebRTC 是实时媒体栈。
构建在 UDP + SRTP 之上，核心目标是“低延迟的实时音视频通信”。
它专门为双向语音、视频、会议与实时 AI 对话设计，
支持丢包容忍、码率自适应、加密与 NAT 穿透等特性。
从本质上说，WebSocket 关注“可靠传输”，WebRTC 关注“自然交流”。
在 对话式 AI 系统里，这个区别决定了后续一切的体验质量。
3.3 为什么 WebRTC 更适合 对话式 AI
WebRTC 的优势不仅在“速度”，而在于它把语音交互的复杂性封装在协议里。 下面从四个维度解释它为何是语音代理的标准答案。
3.3.1 传输机制与实时性：让声音“现在发生”
语音 AI 的目标并不是“零延迟”，而是让交互听起来自然、顺畅。
大量实测显示：800ms –1.5 秒 的响应延迟是会被认为是“自然舒适”的。但若超过 2 秒，对话开始出现不连贯感；超过 3 秒，用户会误以为系统卡死或失效。
WebSocket 基于 TCP，所有包都必须按序送达。任何一个音频包的延迟或丢失，都会触发重传与阻塞（Head-of-Line Blocking），后续所有数据都会被拖慢。在弱网或移动网络下，这会造成端到端延迟轻松突破 2 秒，有时甚至达到 3 秒以上。这不仅让对话节奏变慢，还让语音交互失去“呼吸感”。
WebRTC 走 UDP 路线。它允许按需丢弃过期帧，优先传递最新音频，并自动做前向纠错（FEC）与码率调节。在网络波动 10–15% 的情况下，它仍能把整体响应控制在 1–1.5 秒。
体验上，WebSocket 等于“等到完美”，WebRTC 等于“立刻回应”。
3.3.2 实时控制与打断语义：像人一样“插话”
人类的对话不是线性的。我们经常在对方说话时插话、回应、打断。要做到这种“自然轮换”，系统必须能在毫秒级控制媒体流。
WebSocket 只是数据通道，不理解音频帧或时序；开发者需要手动实现“打断协议”，包括：停止播放、取消生成、清空缓存、恢复监听等。这一整套逻辑复杂又容易延迟。
WebRTC 则天生支持流式播放与 RTP 时间戳控制，可以让播放与采集线程独立运行。当检测到新语音输入（通过 VAD/轮次检测），可以立即停止当前播放，切换到收听状态，整个过程无感。这种“边说边听”的能力，正是语音代理与普通聊天机器人的分水岭。
3.3.3 设备与信号处理：从“听得清”开始
真实设备的输入并不干净。回声、风噪、键盘声、麦克风距离，都会影响识别质量。
WebRTC 自带完整的 3A 处理链：AEC（回声消除）、ANS（降噪）、AGC（自动增益控制），能在底层完成音频修复，让送入 ASR 的信号更稳定、更可识别。
WebSocket 路线没有这些能力。开发者必须自行集成第三方 DSP 库、处理多平台兼容与性能问题。结果往往是：你为了补全音质，手动造了一个迷你 WebRTC。
3.3.4 可观测性与可维护性：看得见，才调得好
当延迟或音质问题出现时，能否快速定位，是系统是否可维护的关键。
WebRTC 内置完整的 getStats() 接口与媒体统计系统，实时上报 RTT、丢包、抖动、码率、音量电平、缓冲深度等指标。开发者可以从端到端精确判断延迟发生在哪个环节。
WebSocket 只是一条黑箱字节流。要追踪类似指标，必须在应用层人工埋点、对齐时间戳、分析日志，成本高且容易误判。
WebRTC 把“诊断能力”作为协议一部分，而 WebSocket 完全依赖应用自建。
3.4 复杂 ≠ 困难：WebRTC 的学习曲线与收益比
的确，WebRTC 的协议栈更复杂。它涉及 SDP、ICE、DTLS、SRTP、RTP 等多个子层，对新手而言学习曲线陡峭。但这种复杂性换来的是工程确定性。 你不必自行重造：
拥塞控制
音频处理
延迟补偿
NAT 穿透
安全加密
QoS 监控
这些都是 WebRTC 已经标准化并持续优化十余年的成果。学习一次 WebRTC，相当于获得一个完整的实时语音系统内核。
因此，与其“用 WebSocket 拼出一个能跑的 demo”，不如“用 WebRTC 构建一个能活的系统”。