有哪些通讯协议，ChatGPT 的对话功能实现选择什么协议

温暖全栈
371 阅读3分钟

一、常见的实时通信协议

  1. HTTP轮询（Polling）
    • 原理：客户端定期向服务器发送请求以获取新数据。
    • 特点：简单但效率低，频繁请求可能导致资源浪费和延迟。
  1. HTTP长轮询（Long Polling）
    • 原理：客户端发送请求后，服务器保持连接开放直到有新数据或超时。
    • 特点：减少无效请求，但仍依赖客户端发起，实时性有限。
  1. WebSocket
    • 原理：基于TCP协议的全双工通信，客户端与服务器建立持久化双向连接。
    • 特点：低延迟、双向交互，适合聊天室、在线协作等场景，但协议复杂且资源消耗较高。
  1. Server-Sent Events（SSE）
    • 原理：基于HTTP的单向服务器推送技术，客户端通过EventSource监听事件流。
    • 特点：轻量级、支持断线重连、数据格式灵活（如文本或JSON），适合单向实时更新场景。

二、ChatGPT选择SSE协议的原因

  1. 单向通信需求
    ChatGPT的对话场景本质是“一问一答”，用户发送请求后，服务端持续生成响应并分片返回，无需客户端频繁交互。SSE的单向推送特性完美契合这一需求。
  2. 流式传输与用户体验
    • 大语言模型生成响应耗时较长，SSE支持“边计算边返回”（流式传输），逐词或逐句推送结果，模拟“打字机”效果，减少用户等待焦虑。
    • 若采用HTTP一次性返回，用户需等待完整响应生成，可能因延迟关闭页面。
  1. 资源效率与兼容性
    • 低开销：SSE基于HTTP协议，无需额外协议握手，服务端实现简单，适合高并发场景（如ChatGPT日均亿级请求）。
    • 浏览器支持：现代浏览器原生支持EventSource，无需复杂兼容处理。
  1. 与WebSocket的对比
    • 全双工 vs 单向：WebSocket的双向通信能力在ChatGPT场景中冗余，SSE更轻量。
    • 连接管理：SSE内置断线重连和事件ID追踪机制，减少开发复杂度。

三、SSE的技术实现要点

  1. 服务端配置
    • 响应头需包含 Content-Type: text/event-stream 和 Cache-Control: no-cache。
    • 数据格式为多行文本，例如：
event: message
data: {"content": "生成文本片段"}
\n\n
  1. 客户端监听
    • 使用JavaScript的EventSource对象建立连接，通过onmessage事件处理推送数据：
const source = new EventSource('/sse-endpoint');
source.onmessage = (event) => { console.log(event.data); };
  1. 异步与性能优化
    • 服务端需异步处理长连接（如Spring Boot的SseEmitter或Tornado异步框架），避免线程阻塞。

四、总结

ChatGPT选择SSE协议的核心原因在于其轻量级、单向推送和流式传输能力，既满足了实时交互需求，又降低了服务端资源消耗。相比之下，WebSocket更适合双向高频交互场景（如在线游戏），而传统HTTP轮询在效率和实时性上均不足。对于类似的大规模语言模型应用，SSE是实现流式响应的理想选择。

avatar
文章
阅读
粉丝