标准回答
SSE：服务端单向推送，LLM 流式的默认选择
Server-Sent Events 跑在普通 HTTP 之上，服务端通过一条长连接持续把事件推给浏览器，浏览器原生 EventSource 还自带断线自动重连。它只有「下行」一个方向，而 LLM 把生成的 token 逐个吐给前端正好是单向场景，所以纯文本聊天的流式输出用 SSE 最简单：无需额外协议、对网关/代理友好、实现成本低。局限是只能下行，客户端要发新消息得另开 HTTP 请求，且并发连接受 HTTP 连接数限制。
WebSocket：全双工，需要持续上行时上场
WebSocket 握手后是一条全双工长连接，上下行都走同一条通道，帧开销小、延迟低。当客户端需要在服务端持续输出的同时不断上行——例如语音对话里边说边收、用户随时「打断」模型、多人协作实时同步——SSE 的单向就不够用了，WebSocket 是自然选择。代价是需要自己处理心跳保活、断线重连和消息边界，状态管理比 SSE 复杂。
WebRTC：媒体级 P2P，端到端实时语音/音频
WebRTC 面向音视频流，走 P2P（或经 TURN 中转），延迟可压到几十毫秒级，并内建回声消除、降噪、抖动缓冲、自适应码率这些媒体处理能力。真正的「实时语音对话」（如 Realtime API 这类边听边说、可随时打断的语音 Agent）用 WebRTC 才能拿到自然的体验。代价是架构最复杂：需要信令服务器交换 SDP/ICE、可能要部署 STUN/TURN，调试门槛高。
取舍小结
纯文本流式 → SSE 够用且最省事；需要客户端持续上行/可打断 → WebSocket；端到端实时语音音频 → WebRTC。很多产品会混用：文本走 SSE，语音通道走 WebRTC，控制信令走 WebSocket。
常见误区
⚠️ 常见踩坑
别一上来就给纯文本聊天套 WebSocket 或 WebRTC——只需要下行流式 token 时 SSE 更简单、更稳、更易扩展；反过来，想做低延迟实时语音却硬用 WebSocket 传 PCM，会因为缺少回声消除/抖动缓冲而体验很差。
追问
追问 1：SSE 有哪些坑需要注意？
主要是单向（客户端发消息要另开请求）、受浏览器对单域名 HTTP 连接数的限制、某些代理会缓冲或断开长连接。HTTP/2 多路复用能缓解连接数问题；还要设置合理的重连与心跳注释行（: keep-alive）防止中间设备超时断连。
追问 2：WebSocket 为什么仍然需要心跳与重连机制？
长连接会被负载均衡、反向代理或移动网络的空闲超时悄悄掐断，而 TCP 层不一定及时感知。所以要用 ping/pong 心跳探活、检测到断开后做指数退避重连，并在应用层补发/去重未确认消息，保证对话状态不丢。
追问 3：WebRTC 的信令是做什么的，为什么必须自己搭？
WebRTC 标准只规定媒体如何传，不规定两端怎么「找到彼此」。信令服务器负责交换 SDP（编解码与媒体能力）和 ICE 候选（网络地址），完成连接协商；它可以用 WebSocket 实现。NAT 穿透还常需 STUN 获取公网地址、TURN 在直连失败时中转，因此 WebRTC 整体部署比前两者重。
🔗 相似问题
同一考点的不同问法，面试官可能换着问，一起刷更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习