「Agent Tool」LLM 通信协议怎么选：SSE、WebSocket 与 WebRTC

0 前言

本文内容整理自公众号「小林面试笔记」的文章 14. 说说 WebSocket 和 SSE 通信的区别及局限性？ 和 15. 为什么要用 WebRTC 协议？它和 WebSocket（WS）在 AI 对话流中的核心差异是什么？，用于记录与总结 AI Agent 工具调用相关的核心面试知识点。

「WebSocket 和 SSE 通信有什么区别？为什么实时的 AI 语音对话要用 WebRTC 而不是 WebSocket？」，可以这样作答：

这是两道连在一起考的题，本质在问「LLM 对话里通信协议怎么选」。通信方向不同是 SSE 与 WebSocket 的本质差异：SSE 是 HTTP 原生特性，服务端沿一条长连接单向推送，适合 LLM 流式输出文字；WebSocket 是独立协议，一条连接全双工，适合需要中途双向交互的场景（打断、协同编辑）。两者各有明确局限，选型看场景——单向推送用 SSE，真正双向才上 WebSocket。

实时语音是另一套需求：语音容忍丢包、绝不容忍延迟。WebSocket 走 TCP，丢包强制重传会让延迟堆积、实时体验崩溃；WebRTC 建在 UDP 之上，丢包用插值填补（丢包隐藏）而不是等待重传，把延迟稳定压在 50-150ms，还内置回声消除、噪声抑制、自适应码率等音频处理能力。OpenAI Realtime API 等实时语音产品选 WebRTC，正是因为 TCP 系方案在丢包时延迟不可控。

一句话选型：文字对话用 SSE 或 WebSocket，实时语音用 WebRTC——三者不是替代关系，实时语音产品里往往还要用 WebSocket 做信令通道、用 WebRTC 传音频。

如今 ChatGPT、Claude 网页端打字机式的流式输出，底层走的就是 SSE——打开开发者工具，能看到连接里一条条 data: {...} 的数据流；而 OpenAI Realtime API 这类实时语音对话走的是 WebRTC，音频在 UDP 通道上低延迟流动。有意思的是两者可以在一个产品里共存：浏览器里用 SSE 推文字、用 WebRTC 传语音。MCP 的远程传输里也藏着一个 SSE——Server 向 Client 流式推送时底层用的就是它，这套传输设计的来龙去脉我们第 8 篇详细讲过。这篇把三种协议放到一起，说清楚各自的取舍与适用场景。

1 先看清需求：LLM 对话里其实有两条数据流

选型之前先想清楚一个问题：LLM 对话（聊天、语音）为什么不能像普通网页那样「请求一次、返回一次」？

  • HTTP 天然是「一问一答」：客户端发请求、服务端回响应，一次交互就结束，服务端不能主动往客户端推数据。而大模型生成内容要好几秒，用户看到的是「逐字蹦出来」的效果——模型生成一点就要推一点，连接必须一直保持打开。

HTTP 请求-响应的一问一答模式示意

  • 文字和语音对网络的要求完全不同：
    • 文字：要求准确、有序、完整，TCP 的可靠传输是刚需；
    • 语音：人脑对时序极度敏感，超过 200ms 就感到卡顿，超过 400ms 会「说话串线」；丢掉 20ms 的音频人耳几乎感知不到，但为了等它重传、把后续音频全部堵住，体验直接崩溃。

文字流与语音流对网络的需求差异对比

结论一句话：文字传输要求「可靠」，语音传输要求「及时」——语音容忍丢包，绝不容忍延迟。后面所有选型的合理性都从这里来。

2 文字流的第一种选择：SSE——用普通 HTTP 撑开一条单向水管

SSE（Server-Sent Events）不是新协议，它是 HTTP/1.1 原生特性的「巧用」：

  • 客户端发请求时带上 Accept: text/event-stream，声明「我要一条事件流」；
  • 服务端收到后不关连接，把响应体当成一条持续开放的通道，按约定的文本格式一条条往下写。

消息就是纯文本，每行以 data: 开头、以两个换行结尾——你在 ChatGPT 的开发者工具里看到的流式返回 data: {"token": "你"} 就是这个格式；浏览器 EventSource API 一行代码接上、onmessage 回调直接收，连解析都省了：

1
2
3
4
5
data: {"token": "你"}

data: {"token": "好"}

data: {"token": "，"}

SSE 用 HTTP 长连接单向推送数据流示意

「撑开通道、持续推数据」是 HTTP 协议本来就允许的能力，不需要新协议、不需要像 WebSocket 那样做握手升级，任何 HTTP 代理都能透传，运维成本最低；它的问题在于单向——用户中途想打断模型输出，只能断开当前流、重新发一个带停止指令的请求，链路是割裂的。这个短板在讲完 WebSocket 后对比更明显。

3 文字流的第二种选择：WebSocket——从 HTTP 升级成真正的双向信道

WebSocket 和 SSE 最大的区别不在「能力大小」，而在通信方向：

  • 握手时客户端发一个带 Upgrade 声明的 HTTP 请求，服务端回 101 Switching Protocols，之后这条 TCP 连接升级为全双工信道——从「对讲机」变成「电话」：任何一方随时可以说话，不用等对方说完；
  • 同一个例子看差异：打断模型输出时，WebSocket 里客户端在同一条连接内直接发一条停止指令对方就能收到，交互流畅、状态连贯，没有 SSE 那种「断流 + 重发」的割裂感。

WebSocket 从 HTTP 升级为全双工信道示意

所以记住本质差异是通信方向（SSE 服务端单向推、WebSocket 全双工），而不是「WebSocket 更强所以更好」——WebSocket 复杂度更高，必须有真实需求（打断、协同、双向往来）才值得上。

4 各自的局限：SSE 的三坑与 WebSocket 的三坑

选型不能只看优点。两边都有明确的短板，面试官追问时往往就挖在这里。

SSE 的三个局限：

  • 单向性带来「双通道尴尬」：用户消息走 POST、模型回复走 SSE，两条通道要靠 conversation ID 关联，状态管理复杂；
  • HTTP/1.1 下同域名最多 6 条并发连接：第 7 个页面就得排队等待，体验「卡死」（HTTP/2 多路复用可解，但引入了新要求）；
  • 只能传文本：传语音、图像得先 Base64 编码，体积膨胀约 33%——实时语音对话对这个膨胀完全不能接受，这也为后面「实时语音得换协议」埋下伏笔。

SSE 单向性带来的双通道复杂度示意

WebSocket 的三个局限：

  • 有状态：连接建在哪台服务器，会话状态就存在哪台——横向扩容要么做会话保持，要么把状态外移到 Redis 发布订阅，都更复杂、多一跳网络；
  • 代理/防火墙穿透难：握手的 Upgrade 请求不是普通 HTTP GET/POST，企业 HTTP 代理、老 CDN 不识别会直接拒绝；SSE 始终是普通 HTTP，任何代理都能透传——这正是早期 MCP 远程传输选 SSE 而不是 WebSocket 的原因（演进细节见第 8 篇）；
  • 没有内置请求-响应配对：WS 是双向消息，谁回谁靠自己加请求 ID、维护映射表，重试逻辑也要自己设计。

WebSocket 有状态导致横向扩展麻烦示意

WebSocket 升级握手被代理拦截示意

5 实时语音场景：为什么是 WebRTC 而不是 WebSocket

把语音放进 WebSocket（TCP 通道），最大的问题是丢包时的策略：

  • TCP 看见丢包就重传——为了 20ms 的音频片段，后续所有音频都得排队等它，延迟像滚雪球一样堆积，「实时」彻底泡汤；
  • 语音里延迟重过丢包：丢 20ms 人耳无感，卡顿 200ms 用户就想挂电话。

WebRTC 的方案是主动放弃可靠性：底层换成 UDP，丢包就丢包、不重传不等待；缺失的音频片段用**丢包隐藏（Packet Loss Concealment，PLC）**技术，拿前后帧插值填补——用偶尔的轻微音质损失，换稳定在 50-150ms 的低延迟。实时音频场景里，这笔账划算。

WebRTC 基于 UDP 的丢包隐藏策略示意

这里有个反直觉的点：UDP 的「不可靠」不是偷懒，而是刻意的设计选择——在实时音频里，可靠性让位于时延，是协议层一开始就定好的取舍。

6 WebRTC 不是单一协议：协议栈、SDP 信令与 NAT 穿透

面试的加分点在于：WebRTC 不是「UDP 传音频」这么简单，它是一整套协议组合：

  • UDP：低延迟传输的地基；
  • DTLS：UDP 版 TLS，负责密钥协商与加密——UDP 上照样要安全；
  • SRTP：加密传输媒体数据，RTP 包自带时间戳和序列号，配合 RTCP 持续监控丢包与网络质量；
  • ICE：连接建立阶段的 NAT 穿透框架。

WebRTC 协议栈组成：UDP、DTLS 与 SRTP

在此基础上还有两个关键机制：

  • SDP 信令：真正传音频之前，双方先交换一份「协商书」——支持哪些编解码格式、网络地址、加密参数。注意 WebRTC 只规定了 SDP 这个格式，不规定信令通道用什么传，WebSocket、HTTP 都行。所以实时语音产品里最常见的架构是：用 WebSocket 传信令，用 WebRTC 的 UDP 通道传音频——两者各司其职、配合而非替代。这是面试官最爱挖的一句话。
  • NAT 穿透的三级降级：同局域网直接连（延迟最低）→ 打洞失败就用 STUN 发现公网 IP:端口、尝试建立 P2P → 还不行就 TURN 中转（失去 P2P 的低延迟优势，但保证连通）。最常见的失败场景是对称 NAT——企业防火墙、运营商级 NAT 每换一个目标就换一个出口端口，STUN 探测到的端口在对端连接时早就变了。

SDP 信令交换协商双方能力示意

ICE/STUN/TURN 的 NAT 穿透策略示意

7 内置音频处理与 OpenAI Realtime API 的选型

WebSocket 传语音还有一个隐性成本——音频处理全要自己造轮子。WebRTC 原生自带一套：

  • AEC 回声消除：扬声器的声音被麦克风采回去形成反馈循环，先消掉；
  • NS 噪声抑制：过滤环境噪声、只留人声；
  • AGC 自动增益控制：音量忽大忽小自动拉平；
  • ABR 自适应码率：RTCP 反馈网络状况，好网给高码率、差网降码率保流畅。

WebRTC 内置回声消除等音频处理能力

OpenAI Realtime API 选 WebRTC 作为媒体传输层，理由就摆在那：它要求端到端延迟低于 300ms、双向同时说话、随时打断、回声消除——TCP 系的 WebSocket 在网络抖动丢包时达不到延迟要求，音频处理能力也得从零实现；WebRTC 天然满足全部条件。

OpenAI Realtime API 选择 WebRTC 的原因

8 三种协议横向对比与选型原则

先看场景怎么选：

场景 推荐方案 原因
LLM 流式文字输出（ChatGPT 风格） SSE 单向推送够用，HTTP 原生、轻量、运维简单
多轮文字对话（用户发消息 + 模型回复） SSE + 普通 POST 发消息走 POST、回复走 SSE，解耦简单
需要用户中途打断模型输出 WebSocket 需要客户端流式中途主动发消息
多人协同编辑、实时同步 WebSocket 频繁双向消息，SSE + POST 双通道太繁琐
实时语音对话 WebRTC 音频流需要 UDP + 低延迟，WebSocket 的 TCP 重传是瓶颈
MCP 远程 Server Streamable HTTP（内部 SSE 流式） 单端点、代理穿透友好（详解见第 8 篇）

再看 WebSocket 与 WebRTC 的核心维度差异：

维度 WebSocket WebRTC
底层协议 TCP UDP
连接模式 客户端 <-> 服务器 P2P 直连（可降级 TURN 中转）
延迟 50-500ms（受 TCP 重传影响） 50-150ms（UDP 不重传）
丢包处理 强制重传、后续数据等待 丢包隐藏、插值填补、不阻塞
音视频支持 无，需自行实现 原生：编解码、AEC、NS、AGC、ABR
连接建立 简单，HTTP Upgrade 复杂：信令交换 + ICE NAT 穿透
适合场景 文字/数据实时双向通信 实时音视频通话
实现复杂度 低 高（信令服务、STUN/TURN 需自建或云服务）

选型就三句话：单向推文字用 SSE；真双向的文字/数据交互用 WebSocket；实时语音用 WebRTC。WebRTC 运维复杂度最高，但在 AI 语音助手这类产品里，低延迟和音频质量是值得的。

9 面试总结

回答这类题，最常见的误区是把三者混淆成「强 vs 弱」或「替代关系」。先避开几个雷：

误区 正解
SSE 是 WebSocket 的简化版 两者是独立的两样东西：SSE 是 HTTP 原生特性（单向），WebSocket 是独立协议（全双工），本质差异在通信方向
WebSocket 功能强大所以更好 复杂度高、有明确短板；单向推送场景 SSE 更轻更省——OpenAI、Anthropic 的流式输出都选 SSE
WebRTC 只是「P2P、延迟低」 核心差异是底层协议：WS 走 TCP（重传导致延迟不可控），WebRTC 走 UDP（丢包隐藏换稳定低延迟），外加原生音频处理能力
实时语音用 WebSocket 也行 / WebRTC 会取代 WebSocket 语音用 WebRTC 是需求倒逼；WebRTC 建连时常需要 WebSocket 做信令通道，两者配合而非替代

再按这张框架组织答案：

框架 要点
根本需求 文字要可靠（TCP 刚需）、语音要及时（>200ms 卡顿、>400ms 串线）；「语音容忍丢包、绝不容忍延迟」
本质差异 SSE 是 HTTP 原生单向长连接；WS 是独立协议、全双工；WS 丢包延迟不可控，WebRTC 用丢包隐藏插值换 50-150ms 稳定低延迟
各自局限 SSE：单向双通道复杂、HTTP/1.1 同域 6 连接上限、只能传文本（Base64 膨胀约 33%）；WS：有状态难扩容、代理拦截 Upgrade、无内置请求-响应配对
加分项 SDP 信令 + ICE/STUN/TURN 打通 NAT；「WebRTC 用 WebSocket 做信令、配合而非替代」；AEC/NS/AGC/ABR 原生音频处理

追问预案：

  • 「为什么 ChatGPT 用 SSE 而不用 WebSocket？」——流式输出是单向推送，SSE 不需要握手升级、任何代理可透传、实现运维都简单，足够满足需求。
  • 「SSE 能传二进制吗？」——不能。只能传文本，传语音、图像要 Base64 编码、体积膨胀约 33%，所以实时语音场景得换 WebRTC。
  • 「为什么 WebSocket 握手会被企业代理拒绝？」——Upgrade 请求不是普通 HTTP GET/POST，部分企业代理、老 CDN 不识别就拒绝；这也是早期 MCP 远程传输选 SSE 不选 WebSocket、后来升级到 Streamable HTTP 的原因之一（详见第 8 篇）。
  • 「WebRTC 建连可以用 WebSocket 吗？」——可以，而且这是常见架构：WebRTC 只规定 SDP 信令格式、不规定传输方式，用 WebSocket 传信令、UDP 传音频，两者配合而非替代。
  • 「WebRTC 丢包了怎么办？」——不重传。用丢包隐藏（PLC）拿前后帧插值填补，偶尔轻微音质损失换稳定低延迟；另外由 RTCP 反馈驱动 ABR 自适应码率，差网自动降码率保流畅。

参考

本文图片均来源于公众号「小林面试笔记」，版权归原作者所有。

追逐繁星 > Agent Tool
#AI #Agent #大模型 #LLM
「Agent Tool」LLM 通信协议怎么选：SSE、WebSocket 与 WebRTC
https://marisamagic.github.io/2026/08/20/20260820_SSE_WebSocket_WebRTC对比/
作者
MarisaMagic
发布于
2026年8月20日
许可协议