为什么大模型网站使用 SSE 而不是 WebSocket?

浅析即时通讯开发WebSocket热门疑问 通俗地说,Nginx只能帮助完成引导WebSocket客户连接到哪一个WebSocket服务端实例,在IM集群情况下,如果两个用户处于不同的WebSocket实例下时,它们之间的跨实例通信,Nginx是没有办法实现的,这一块的逻辑还是得IM开发者自已来实现。WebSocket是一种比较新的协议,它是伴随着html5规范而生的,虽然还比较年轻,但大多主流浏览器都已经支持。长轮询,就是客户端发送一个请求,服务端将一直在这个连接上等待(当然有一个超长的超时时间),直到有数据才返回,它依然是一个一问一答的模式。.. 阅读详情
AI摘要

大模型网站前端常使用 SSE 与后端对接,而非 WebSocket。文章详细对比了 SSE、WebSocket、HTTP 长轮询和 gRPC 的特点、缺点及适用场景。指出 SSE 更适合流式文本生成场景,具有轻量级、自动重连等优势,是大模型流式返回的最佳方案。

在大模型网站(如 ChatGPT、Claude、Gemini 等)中,前端通常使用 EventSource(Server-Sent Events, SSE) 来与后端对接,而不是 WebSocket。这是因为 SSE 更适合类似流式文本生成的场景。下面我们详细对比 SSE、WebSocket 和其他可选方案。


1. SSE(Server-Sent Events,服务器发送事件)

特点:

  • 单向通信(服务器 → 客户端),适用于大模型输出流式文本的场景。
  • 基于 HTTP/1.1 及 EventSource API,兼容性较好,易于集成。
  • 自动重连,如果连接断开,浏览器会自动尝试重新连接。
  • 轻量级,开销小,适合传输文本数据。

缺点:

  • 只支持 服务器推送,客户端无法主动发送消息(需要用 AJAX/Fetch 结合)。
  • 受 同源策略 影响,跨域时需要 CORS 配置。
  • 在 HTTP/2 之前,SSE 只能打开 6 个连接(浏览器限制),但在 HTTP/2 上可复用单连接,问题减小。

适用场景:

✔ 流式返回(如 ChatGPT 逐字输出)
✔ 服务器向前端持续推送数据(如股票行情、日志监控)


2. WebSocket

特点:

  • 全双工通信,客户端和服务器可以随时相互发送数据。
  • 基于 TCP,独立于 HTTP,但通常通过 HTTP/HTTPS 协商(ws:// 或 wss://)。
  • 低延迟,适用于高频交互(如实时聊天、游戏、协作编辑)。

缺点:

  • 连接管理复杂(心跳检测、断线重连、负载均衡较难)。
  • 代理/防火墙兼容性问题,某些企业网络可能会阻止 WebSocket。
  • 服务器资源占用更大,需要维护长连接,占用线程/内存。

适用场景:

✔ 双向实时交互(如在线协作、弹幕、游戏匹配)
✔ 低延迟高频数据更新(如金融交易、物联网)

为什么大模型网站不用 WebSocket?

  • WebSocket 适用于双向通信,而 大模型的输出是“流式”文本,客户端只需接收数据,WebSocket 的优势无法体现。
  • WebSocket 需要额外的 连接管理,而 SSE 依赖于现有的 HTTP 连接,更易集成。

3. HTTP 长轮询(Long Polling)

特点:

  • 客户端发送请求,服务器 保持连接不返回数据,直到有新数据才返回。
  • 客户端收到数据后立即发送新的请求,模拟流式通信。
  • 兼容性极好,所有 HTTP 服务器都支持。

缺点:

  • 请求开销大,每次返回数据后都需要重新建立 HTTP 连接,浪费资源。
  • 延迟较高,如果服务器没有数据,客户端必须定期请求,效率低。

4. gRPC(基于 HTTP/2 的流式通信)

特点:

  • 双向流式通信(客户端和服务器都可以持续发送数据)。
  • 基于 HTTP/2,性能较好,可在单个连接上多路复用请求。
  • 适用于微服务通信,比 REST API 更高效。

缺点:

  • 浏览器原生不支持,需要使用 gRPC-Web 代理转换。
  • 复杂度高,部署比 SSE/WebSocket 难。

总结:哪种方式适合大模型前端?

方案是否适用于大模型流式返回?特点适用场景
SSE(EventSource)✅ 最佳选择服务器 → 客户端单向推送,轻量、自动重连流式输出(ChatGPT)、实时通知
WebSocket❌ 过度设计双向通信,低延迟,复杂连接管理聊天、游戏、协作编辑
长轮询(Long Polling)❌ 开销大兼容性强但效率低,每次数据返回后需重新请求旧系统支持
gRPC(HTTP/2 流)❌ 需要代理双向流式,高性能,浏览器需 gRPC-Web微服务、API 交互

📌 所以,SSE 是最佳选择:

  1. 天然支持流式输出,非常适合 ChatGPT 这类逐字返回的内容。
  2. 轻量级、简单易用,只需 EventSource API,不需要额外的连接管理。
  3. 支持 HTTP/2,比 WebSocket 适合这类请求响应模式。

实际应用示例(基于 SSE 实现大模型流式输出)

前端代码(使用 SSE 监听服务器消息):

const eventSource = new EventSource('/chat/stream');  // 后端返回流式数据

eventSource.onmessage = (event) => {
  console.log('收到新消息:', event.data);
};

eventSource.onerror = () => {
  console.log('连接断开,尝试重连...');
  eventSource.close();
};

后端代码(Node.js 示例):

app.get('/chat/stream', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');

  let count = 0;
  const interval = setInterval(() => {
    res.write(`data: 你好,消息 ${count++}\n\n`);
    if (count > 5) {
      clearInterval(interval);
      res.end();
    }
  }, 1000);
});

结论

SSE 是 最适合大模型流式返回的方案,因为它:
✅ 轻量级
✅ 自动重连
✅ 支持 HTTP/2
✅ 适用于服务器单向推送

所以,大模型网站普遍使用 SSE,而不是 WebSocket! 🚀

网站截图

DeepSeek

请添加图片描述

ChatGPT请添加图片描述

Claude请添加图片描述

文心一言请添加图片描述

→ 以上 🐒

服务端实时推送技术之SSE(Server-Send Events) 服务端推送,也称为消息推送或通知推送,是一种允许应用服务器主动将信息发送到客户端的能力,为客户端提供了实时的信息更新和通知,增强了用户体验。 阅读详情

相关推荐

SSE 和 Websocket 的比较

本文详细解析了SSE和WebSocket这两种实现实时通信的技术。SSE是一种基于HTTP的单向通信机制,适用于实时更新数据的应用场景。WebSocket是一种全双工通信协议,支持双向通信,适用于实时互动的应用场景。它们在通信模型、连接性、实时性、浏览器支持和API复杂性等方面存在一些区别。选择SSE还是WebSocket取决于您的应用需求。如果您只需要服务器向客户端推送数据,并且实时性要求不高,SSE是一个简单可行的选择。

weixin_42560424的博客 9648

SSE(Server-Sent Events)技术及其简单演示

SSE(Server-Sent Events)是一种用于实现服务器主动向客户端推送数据的技术,也被称为“事件流”(Event Stream)。它基于 HTTP协议,利用了其长连接特性,在客户端与服务器之间建立一条持久化连接,并通过这条连接实现服务器向客户端的实时数据推送。

qq_61887118的博客 3万+

调试|谷歌浏览器调试长连接|调试SSE和websocket

长连接需求不常有,控制台调试的细节容易忘,在这截图备忘。本文会记录SSE、websocket协议接口、一般的接口(http协议接口) 在谷歌浏览器控制台的对比

你个无聊小demo的博客 1622

为什么websocket没有被广泛使用,他解决了前后端数据没有实时刷新的问题,原因来了。

为什么接口不全部采用websocket,最近在开发一个项目,里面有im实时聊天,用到了websocket,而我仅仅是聊天室用了,其他聊天记录已经人员邀请创建群里采取的都是http请求,数据需要实时交互目前前端实现方法就是类似于ajax轮询,定时请求接口数据,都知道这样一来比较浪费带宽,二来服务器端的压力会很大,所以在websocket出来前用的都是轮询,但websocket出来以后,按说解决了数据交互的问题,如果每个接口都做成websocket模式,岂不是不存在数据不刷新,都是实时显示的了,为什么http还

海贼王某人的博客 6471

实时通讯技术Ajax,WebSocket,SSE

简要介绍ajax,websocket,sse三种通讯的简要使用。

个人学习笔记库,一篇一篇记录成长的足迹 4862

WebSocket vs SSE: 实时数据推送到前端的选择与实现(详细)

对比实现Websocket和sse推送给前端数据选择与实现,以及各自的弊端,适用场景等等

todoitbo的博客 2万+

从 WebSocket 到 SSE,大模型应用绕不开的 SSE

这是一种非常适合实时数据推送的技术。与 WebSocket 不同,SSE 只支持服务器到客户端的单向通信。它是基于 HTTP 协议的,能够让服务器推送数据到客户端。简单来说,SSE 就是让服务器能够在不需要客户端不断请求的情况下,主动推送数据。

weixin_50367873的博客 870

别再只做游戏了!用虚幻引擎5(UE5)给你的工厂车间做个数字双胞胎(附数据对接教程)

本文详细介绍了如何利用虚幻引擎5(UE5)构建工业数字孪生系统,实现工厂车间的智能可视化。通过UE5的高质量渲染和实时数据处理能力,结合OPC UA和MQTT协议,打造高效的数据对接方案,提升异常识别和设备管理效率。文章还分享了模型优化、可视化设计及典型工业场景的实战案例,助力企业迈向工业4.0。

weixin_33738555的博客 206

为什么ChatGPT选择SSE而非WebSocket?

为什么ChatGPT选择SSE而非WebSocket?本文剖析chatGPT回答问题的技术逻辑,然后给出SSE和WebSocket的技术对比。

你的灯在亮 1344

TortoiseGit之配置密钥

基于github的开发必须要用到rsa密钥,因此需要用到TortoiseGit的putty key generator工具,来生成既适用于github的rsa密钥也适用于TortoiseGit的ppk密钥。

欧文的博客 2078

用友u8服务器优化,用友U8erp软件运行的性能优化方案图文教程

今天一定要给大家分享一下用友U8erp软件运行的性能优化方案图文教程,以下方案来自用友软件官方维护工程师反馈在在处理客户问题的时候,有一类问题较为挠头,就是诸如用友U8服务器效率低下的问题。比如用友U8运行慢,卡住等,我们暂先不提用友U8软件代码、脚本层面本身的性能提升问题,我们只是基于现有用友U8软件版本,在客户现有环境下排查用友U8软件运行的性能瓶颈,并采取一定的技术手段进行性能调校。本文将推...

weixin_39882870的博客 5306

为何最近谈论 SSE 和 WebSocket 的人越来越多了?

大模型应用除了带来了 SSE 和 WebSocket 的使用频率越来越高,也在助推 API First 的理念。以往,在线应用都是通过 Service 来对外暴露提供能力,但大模型应用将通过 API 对外提供服务能力,除了基模类厂商已经通过提供 API 来服务广大开发者群体,大模型应用类厂商也开始提供 API 服务。

阿里巴巴云原生的博客 1263

人工智能大语言模型微调技术:SFT 监督微调、LoRA 微调方法、P-tuning v2 微调方法、Freeze 监督微调方法

人工智能大语言模型微调技术:SFT 监督微调、LoRA 微调方法、P-tuning v2 微调方法、Freeze 监督微调方法

丨汀、的博客 4万+

从 SSE 到 WebSocket实时 Web 通信的全面解析与实战

实时通信在现代Web应用中日益重要,传统的Request/Response模式无法满足实时性需求。本文探讨了从短轮询、长轮询到SSE(Server-Sent Events)和WebSocket的技术演进过程。重点分析了SSE的技术特点:基于HTTP协议的单向服务器推送,具有自动重连、断点续传机制,适合日志流、监控指标等场景。文章详细介绍了SSE的消息格式、前端EventSource API的使用方法,以及服务端在Spring MVC和WebFlux中的实现方案。SSE与WebSocket各有所长,前者

hello.reader 1986

学Simulink——基于 Simulink 的 滑模控制(SMC)

本文详细介绍了基于Simulink的Buck变换器滑模控制(SMC)设计与实现方法。首先阐述了传统PI控制在负载突变时的不足,以及滑模控制具有强鲁棒性和快速响应的优势。通过建立Buck变换器的连续状态方程,推导了含积分项的滑模面和控制律,并采用边界层法抑制抖振。文章分步骤讲解了Simulink模型搭建过程,包括主电路、控制器实现和负载扰动模拟模块。仿真结果表明,在负载1A↔5A阶跃时,SMC控制输出电压波动仅0.08V,恢复时间0.35ms,远优于传统PI控制。同时给出了工程实践中的参数选择建议和数字实现技

amy_mhd的博客 253

静态编译Qt5源码(Kylin-Desktop-V10-SP1-2203-LoongArch64+qt5.15.16)

之前的文档,记录的是通用情况,本次笔者记录下Qt5的静态编译过程,供有需要的小伙伴参考使用的操作系统是Kylin-Desktop-V10-SP1-General-Release-2203-LoongArch64,处理器是龙芯3A5000,架构是loongarch。

aggs1990的专栏 1401

SSE与Websocket有什么区别?

SSE和WebSocket是两种实时通信技术,主要区别在于: 协议:SSE基于HTTP(单向),WebSocket为独立协议(双向)。 数据格式:SSE仅支持文本流,WebSocket支持文本/二进制。 性能:SSE有HTTP头部开销,WebSocket二进制帧更高效。 场景:SSE适合服务器推送(如通知),WebSocket适合双向交互(如聊天)。 兼容性:SSE不支持IE,WebSocket兼容IE10+。 选择建议:单向小数据用SSE,双向高频交互用WebSocket。

qq_45089709的博客 1347

RK3588, FFmpeg 拉流 RTSP, mpp 硬解码转RGB

RK3588, FFmpeg 拉流 RTSP, mpp 硬解码转RGB

J。 2339

Springboot 集成 SSE 向前端推送消息

Sse推送Sse介绍特点分析应用场景Spring Boot 集成测试 Sse介绍 sse(Server Sent Event),直译为服务器发送事件,顾名思义,也就是客户端可以获取到服务器发送的事件 我们常见的 http 交互方式是客户端发起请求,服务端响应,然后一次请求完毕;但是在 sse 的场景下,客户端发起请求,连接一直保持,服务端有数据就可以返回数据给客户端,这个返回可以是多次间隔的方式 特点分析 SSE 最大的特点,可以简单规划为两个 长连接 服务端可以向客户端推送信息 了解 websocke

Java老兵的后端进阶与AI前沿探索之路。 1万+

ADT MCP Server 把 ABAP 开发带进 Agent 模式

今天讨论 ADT MCP Server,不能只把它看成 Visual Studio Code 里多出来的一个开关。它真正有意思的地方,在于它把 ABAP 后端开发里那些原本需要手工点击、手工创建、手工激活、手工查服务元数据的动作,包装成一组可以被 GitHub Copilot 这类 coding agent 调用的工具。SAP 在 RAP130 练习里把它描述为运行在 ADT for Visual Studio Code 扩展内部的本地 HTTP Server,它实现的是 Model Context Pro

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 184

怀旧版电脑GBC模拟器

再现原版GBC掌机的界面,电脑运行连游戏界面都一样大小,很怀旧,很真实,(英文版)强烈推荐,很小的文件,很难才找到的。

Web消息推送之SSE

消息推送(push)通常是指网站的运营工作等人员,通过某种工具对用户当前网页或移动设备APP进行的主动消息推送。推送的场景比较多,比如有人关注我的公众号,这时我就会收到一条推送消息,以此来吸引我点击打开应用,消息推送一般又分为web端消息推送和移动端消息推送。另外注意主流浏览器只支持6个连接我有7种实现web实时消息推送的方案,7种短轮询客户端定期向服务器发送请求。如果服务器有更新,它会向客户端发送响应并关闭连接。如果服务器没有更新,它也会向客户端发送一个响应并关闭连接。长轮询客户端向服务器发送请求。...

Shawn的个人博客 1万+

假人有限元模型

假人模型,车辆碰撞假人有限元模型,适合做乘员安全的研究者利用

实时技术对比:SSE vs WebSocket vs Long Polling

本文介绍了三种实现实时通信的技术:SSE(服务器推送事件)、WebSocket和长轮询。SSE适用于单向数据流场景(如股票行情、新闻推送),基于HTTP协议实现简单。WebSocket支持双向通信(如聊天应用),但实现较复杂。长轮询作为传统过渡方案,兼容性好但效率低下。文章通过具体场景对比了三种技术的优缺点:SSE轻量高效但仅支持单向;WebSocket功能全面但复杂度高;长轮询简单兼容但资源消耗大。最后针对股票交易、即时聊天等典型场景给出了技术选型建议,并特别总结了SSE在各种单向实时推送场景中的优势与应

jakeswang的博客 1773

IEM模型,地表粗糙度模拟

利用微波反演土壤水分时候,利用IEM模型可以实现对随机地表的模拟

C# WinForm 基于DirectShow.dll编写的程序,可边预览边保存视频,音频和图片

基于微软的DirectShow.dll的二次开发1.自动识别连接的摄像头跟麦克风且可以对其进行选择(默认选中第一个)2.可录制wmv和avi两种格式的视频并且都带有音频,avi可以录制的分辨率和帧数进行选择,wmv默认进行了淸晰度优化如不喜欢可去除代码中有相关提示3.可在预览点开之后进行拍照,也可边录制视频边拍照4.添加了视频和音频的压缩功能(酌情使用)这次二次开发发现C#对DirectShow的相关信息太少,这次做完也不敢藏私共享出来,还望大家指正

SSE是什么?SSE解决什么问题?在什么场景使用SSE?

SSE的本质是客户端和服务端建立一次持久化的HTTP连接,服务器通过这个连接持续向客户端“流式”发送结构化数据(格式为text/event-stream),客户端实时监听并解析这些数据,实现服务器主动推,客户端被 动收的实时通信。单向通信:仅支持服务器向客户端推送数据,客户端无法通过同一连接向服务器发送数据(若需客户端交互,需额外用 AJAX/HTTP 请求)。基于 HTTP:无需建立新的通信协议(如 WebSocket 的ws://

2302_80222668的博客 1454

短轮询、长轮询、SSE 和 WebSocket 间的区别

短轮询:短轮询是一种客户端与服务器之间的通讯方式,客户端定期向服务器发送请求,以检查是否有新消息。如果没有新消息,服务器会返回一个空响应。这种方法的缺点是客户端发送的请求频率较高,这可能导致网络拥塞和服务器负载过高。长轮询:长轮询是一种改进的轮询方式,其中客户端发送一个请求并保持连接打开,直到服务器有新消息可用或连接超时。这种方法减少了不必要的请求,但仍然需要发送大量的 HTTP 请求。SSE:SSE(Server-Sent Events)是一种单向通信协议,其中服务器可以将消息推送到客户端。

哼哼哼哼哼 2206

DeepSeek之前端利用SSE技术逐步显示推理结果

DeepSeek、文心一言、豆包、通义千问, 大家用这些大模型的时候,都会有一个对话框。你输入问题,然后大模型回答你的答案,都会有一个逐步显示的过程效果,  而不是一次性返回整个答案。开始我以为是使用到了Websocket技术,后端拿到问题以后,逐步往前端推送内容,前端再累加显示整个内容。  但是F12开启以后,没有抓到WS的相关连接信息。 我这就很好奇了,怎么实现这个过程的呢?...

分享不一样的技术,与你一起共同成长! 2624

从 WebSocket 到 SSE,实时通信的轻量化趋势

在实时 Web 的世界里,WebSocket 长期以来一直被视为“黄金标准”。每当我们需要构建聊天应用、在线游戏或协同编辑工具时,它强大的全双工通信能力都使其成为不二之选。然而,在许多场景下,我们真的需要如此“重型”的武器吗?在这些场景中,数据流是的:从服务器到客户端。客户端只是一个被动的接收者。如果这时我们依然选择 WebSocket,就好像为了寄一封信而专门建立了一条双向的私人高速公路——功能强大,但过于复杂且成本高昂。。它用一种极其优雅和简单的方式,完美解决了单向数据推送的难题。

这是一个web全栈开发的博客,取其精华去其糟粕,争取让大家一看就懂,一学就会,一用就成~ 1010
上一篇: JavaScript反调试技术详解:如何保护你的网站代码
下一篇: SSE接口切换页签/页面,接口重复调用问题
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值