本文由45岁老架构师尼恩分享，感谢作者，有修订和重新排版。
1、引言
你有没有想过，为什么 ChatGPT 的回答能逐字逐句地“流”出来？这一切的背后，都离不开一项关键技术——SSE（Server-Sent Events）！
本文从SSE（Server-Sent Events）技术的原理到示例代码，为你通俗易懂的讲解SSE技术的方方面面。
2、初识SSE
SSE（Server-Sent Events）是一种基于 HTTP 协议的服务器推送技术，允许服务端主动向客户端发送数据流。
SSE 可以被理解为 HTTP 的一个扩展或一种特定用法。它不是一个全新的、独立的协议，而是构建在标准 HTTP/1.1 协议之上的技术。
SSE 就像是服务器打开了一个“单向数据管道”，服务器通过HTTP 扩展 可以持续不断地流向浏览器，无需客户端反复发起请求。其实很简单的： SSE = HTTP 扩展字段 + Keepalive 长连接。
SSE 提供了一种简单、可靠的方式来实现服务器向客户端的实时数据推送。它非常适合通知、实时数据更新、日志流和类似 ChatGPT 的逐字输出场景。如果你只需要单向通信，SSE 往往是比 WebSocket 更简单、更轻量的选择。
SSE 适用于服务器主动向客户端推送数据的场景，如实时通知、动态更新等。
所以，目前 几乎所有主流浏览器都原生支持SSE。
4、SSE的诞生背景
4.1短轮询、长轮询、Flash 、 WebSocket
在 SSE 技术出现之前，Web 应用要实现服务器向客户端的实时数据推送，主要依赖以下几种技术，但它们都存在明显的缺陷。
4.1.1）短轮询 (Polling)：
原理：用短连接请求数据。客户端以固定的时间间隔（例如每秒一次）频繁地向服务器发送请求，询问是否有新数据。
缺点：大量请求可能是无效的（无新数据），浪费服务器和带宽资源，实时性差。
短轮询的技术流程图：
4.1.2）长轮询 (Long Polling)：
原理：使用长连接请求数据。 客户端发送一个请求，服务器会保持这个连接打开（长连接），直到有新数据可用或超时。一旦客户端收到响应，会立即发起下一个请求。
缺点：虽然减少了无效请求，但每个连接仍然需要客户端发起，服务器需要维护大量挂起的连接，实现复杂。
长轮询 (Long Polling) 的技术突破：减少无效请求，但服务器需维护挂起连接
4.1.3）基于 Flash 的解决方案：
原理：利用 Adobe Flash 插件提供的 Socket 功能实现全双工通信。
缺点：依赖浏览器插件，在移动端（如 iPhone）不受支持，且随着技术的发展（Flash 被淘汰）已走向消亡。基于 Flash 方法都非原生支持，效率低下或依赖外部插件。
4.1.4）基于 WebSocket的解决方案：
原理：在客户端与服务器之间建立一条全双工的 TCP 长连接，双方可随时互相推送数据。
缺点：
1）需要一次额外的协议升级握手（Upgrade: websocket），对 CDN、防火墙、代理服务器的兼容性不如普通 HTTP；
2）双向通信能力在“服务器→客户端单向推送”场景下显得过度设计，增加心跳、重连、帧解析等复杂度；
3）早期浏览器支持不一（IE ≤ 9 无原生实现），需要 Polyfill 或 Flash 降级方案。
WebSocket全双工通道的革命性：摆脱HTTP束缚，实现真正的实时交互（PS: WebSocket 并不仅是 Web 领域的通讯协议，它属于复杂度较高的二进制通讯协议）。
4.2SSE 诞生的核心背景
因此，Web 领域迫切需要一种标准化的、高效的、由浏览器原生支持的服务器到客户端的单向通信机制。这就是 SSE 诞生的核心背景。
核心需求：
1）简单：易于服务器和客户端实现；
2）高效：基于 HTTP/HTTPS，避免不必要的请求开销；
3）标准：成为 W3C 标准，得到浏览器原生支持；
4）自动重连：内置连接失败后自动重试的机制。
SSE——真正的服务器推送：
5、SSE的前世今生
SSE 的发展是 Web 标准化进程和实时通信需求共同推动的结果。
下图概述了其关键发展节点：
让我们对图中的关键阶段进行详细解读。
1）诞生背景（2006 年以前）：
Web 早期只有“请求-响应”范式，实时需求（股票、IM、行情）只能靠轮询或长轮询，延迟高、浪费资源。Comet（长连接 iframe、jsonp、xhr-streaming 等 Hack 方案）出现，但实现复杂、浏览器兼容性差、占用连接数高。
业界急需一种“浏览器原生、基于 HTTP、单向服务器推送”的轻量机制。
2）概念提出与标准化 (约 2006-2009年)：
SSE 的概念最初作为 HTML5 标准的一部分被提出，由 WHATWG (Web Hypertext Application Technology Working Group) 和 W3C (World Wide Web Consortium) 共同推动。
其设计思想是定义一个简单的、基于 HTTP 的协议，允许服务器通过一个长连接持续地向客户端发送文本流。
2006 年，Opera 9 在浏览器里率先实现名为 Server-Sent Events 的实验 API，用 DOM 事件把服务器推送的文本块喂给页面。
同期 WHATWG HTML5 草案开始收录相关章节，定义了 text/event-stream MIME 类型及“event: / data:”行协议。
后来，它从庞大的 HTML5 规范中分离出来，成为了一个独立的 W3C 标准文档。
2008 年，SSE 被正式写入 HTML5 草案，随后进入 W3C 标准流程。
3）浏览器支持与推广 (约 2010-2015年)：
2011年左右，主流浏览器（如 Firefox、Chrome、Safari、Opera）开始陆续支持 SSE API。 Firefox 6、Chrome 6、Safari 5、Opera 11.5 陆续完成原生实现；IE 系列缺席（直到 Edge 79 才补票）。
关键的障碍：Internet Explorer (包括 IE 11) 始终没有支持 SSE API。这在一定程度上限制了其早期的广泛应用，开发者通常需要为此准备降级方案（如回落到长轮询）。
随着 Chrome、Firefox 等现代浏览器的市场份额不断上升，以及移动端浏览器对 SSE 的良好支持，SSE 逐渐成为开发实时 Web 应用的可信选择。
2014 年 10 月：HTML5 成为 W3C Recommendation，SSE 作为官方子模块锁定最终语法，浏览器阵营格局定型。
4）正式推荐与成熟 (2015年至2022 )：
2015-2020 年，WebSocket 与 WebRTC 占据实时通信话题中心，SSE 主要在企业内部仪表盘、日志 tail 等低频场景默默使用。
SSE 由于有 “单向文本流 + 自动重连 + 轻量” 特性，所以没有被WebSocket 与 WebRTC 踩死， 使其在 IoT 设备、移动端 WebView 中仍保有一席之地。
2015年，W3C 发布了 Server-Sent Events 的正式推荐标准，标志着该技术的成熟和稳定。在此期间，前端生态框架（如 React、Vue.js）和后端语言（如 Node.js、Python、Java）都提供了对 SSE 的良好支持，出现了大量易用的库和示例。
5） 大模型时代的爆发（2022 至今）：
虽然 WebSocket 提供了全双工通信能力，但 SSE 因其简单的 API、基于 HTTP 带来的良好兼容性（如无需担心代理或防火墙问题）、以及自动重连等特性，在只需要服务器向客户端推送数据的场景中（如新闻推送、实时行情、状态更新、AI 处理进度流式输出等）成为了更简单、更合适的选择。
ChatGPT、Claude 等生成式 AI 需要“打字机”式逐 token 输出，SSE 天然契合：
1）基于 HTTP/1.1 无需升级协议，CDN 缓存友好；
2）浏览器 EventSource API 一行代码即可接入；
3）文本流可直接承载 JSON Lines 或 markdown 片段。
2022 年底起：OpenAI、Anthropic、Google Bard 均把 text/event-stream 作为官方流式回答协议，社区库（FastAPI SSE-Star、Spring WebFlux、Node sse.js、Go gin-sse）迎来二次繁荣。
6、SSE的技术特征
SSE和WebSocket 都能建立浏览器与服务器的长期通信，但区别很明显：
1）SSE 是单向推送 不是双向推送， 而且是http协议的一个扩展协议， 使用简单、自动重连，适合文本类实时推送；
2）WebSocket 是双向通信，不是 http协议的一个扩展协议，WebSocket 更灵活，但实现相对复杂。
流程解读：
1）连接初始化：客户端使用特定的 Content-Type: text/event-stream 向服务器发起一个普通的 HTTP GET 请求。服务器确认并保持连接开放。
2）数据推送：服务器通过保持打开的连接，以纯文本格式（遵循 data: ...、event: ... 等规范）持续发送数据块。每个消息以两个换行符 \n\n 结束。
3）连接容错：如果连接因网络问题中断，SSE 客户端内置的机制会自动尝试重新建立连接，极大地提高了应用的鲁棒性。
4）客户端处理：浏览器端的 EventSource API 会解析收到的数据流，触发相应的事件（如 onmessage 或自定义事件），让开发者能够处理推送来的数据。
SSE 的诞生是 Web 开发对简单、高效、标准化的服务器推送技术需求的直接结果。它有效地替代了笨拙的轮询技术，在与 WebSocket 的竞争中，找到了自身在单向数据流场景下的独特定位。
其发展历程经历了从概念提出、浏览器支持到成为正式标准的完整路径。尽管曾受限于 IE，但在现代浏览器中已成为一项稳定、可靠且被广泛采用的技术。如今，在实时通知、金融仪表盘、实时日志跟踪和大型语言模型（LLM）的流式响应输出等场景中，SSE 都是首选的解决方案。
7、默默无闻的SSE为何在AI大模型时代一夜爆火？
SSE 最近站到聚光灯下，几乎可以说最大的推手就是当前 AI 应用（尤其是 ChatGPT 等大型语言模型）的爆发式增长。SSE 之所以成为 AI 应用的“标配”，是因为 SSE 与 AI 所需的“打字机” 输出模式 是 天作之合。
7.1什么是AI大模型“打字机” 式的逐token输出？
“打字机”式 逐 token 输出是一种流式传输方式，它模拟了人类打字或思考的过程。
服务器不是等待 LLM 生成整个答案 后一次性发送给 用户，而是 流式输出， 每生成一个“词元”（token，可以粗略理解为一个词或一个字），就立刻发送这个“词元”。
下面举一个例子，对比 一下 传统方式（非流式）和 “打字机” （流式）式 的过程。
传统方式（非流式）过程如下：
1）你提问：“请写一首关于春天的诗”。
2）服务器端的 AI 开始思考、生成，整个过程你需要等待（可能好几秒甚至更久）。
3）AI 生成完整的诗歌：“春风拂面绿意浓，百花争艳映晴空...”。
4）服务器将整首诗作为一个完整的 JSON 对象 { "content": "春风拂面绿意浓，百花争艳映晴空..." } 发送给客户端。
5）客户端一次性收到全部内容并渲染出来。
“打字机”（流式）过程如下：
1）你提问：“请写一首关于春天的诗”。
2）服务器端的 AI 生成第一个 token “春”，立刻通过 SSE 发送 data: “春”。
3）客户端收到“春”并显示出来。
4）AI 生成第二个 token “风”，立刻发送 data: “风”。
5）客户端在“春”后面追加“风”，形成“春风”。
6）后续 token “拂”、“面”、“绿”、“意”、“浓”... 依次迅速发送和追加。
7）你看到的效果就是文字一个接一个地“打”在屏幕上，就像有人在远端为你实时打字一样。
“打字机”（流式） 模式的巨大优势：
1）极低的感知延迟：用户几乎在提问后瞬间就能看到第一个字开始输出，无需经历漫长的等待白屏期，体验流畅自然。
2）提供了“正在进行”的反馈：看着文字逐个出现，给人一种模型正在为你“思考”和“创作”的生动感，而不是在“沉默中宕机”。
3）更高效地利用时间：用户可以在前半句还在输出时，就开始阅读和理解，节省了总体的认知时间。
7.2为什么SSE跟AI大模型是“天作之合”？
这正是 SSE 的设计初衷和核心优势所在，它与 AI 流式输出的需求完美匹配。
1）单向通信的完美匹配：
AI 的文本生成过程本质上是服务器到客户端的单向数据推送。客户端只需要接收，不需要在生成过程中频繁地发送请求。SSE 的“服务器推送”模型正是为此而生，而 WebSocket 的双向能力在这里是多余的。
2）基于 HTTP/HTTPS，简单且兼容：
SSE 使用标准的 HTTP 协议，这意味着 SSE 易于实现和调试：任何后端框架和前端语言都能轻松处理。在浏览器中调试时，你可以在“网络”选项卡中直接看到以文本流形式传输的事件，非常直观。
SSE 使用标准的 HTTP 协议，这还意味着 容易绕过网络障碍：公司防火墙和代理通常对 HTTP/HTTPS 放行，而可能会阻拦陌生的 WebSocket 协议。这使得 SSE 的部署兼容性极好。
3）内置的自动重连机制：
网络连接并不完全可靠。如果用户在接收很长的回答时网络波动，连接中断，SSE 客户端会自动尝试重新连接。这对于长时间流的应用至关重要，提供了天然的鲁棒性。
4）轻量级的文本协议：
AI 流式输出传输的就是文本（UTF-8编码）。SSE 的协议 data: ...\n\n 就是为传输文本片段而设计的，极其高效和简单。WebSocket 虽然也能传文本，但其协议设计还考虑了二进制帧、掩码等更复杂的情况，对于纯文本流来说显得有些“重”。
5）原生浏览器 API：
现代浏览器都原生支持 EventSource API，开发者无需引入额外的第三方库，即可轻松实现接收流式数据，减少了依赖和打包体积。
所以，SSE 站到聚光灯下的原因正是：
AI 应用需要“打字机”式的逐 token 输出体验，而 SSE 作为一种基于 HTTP 的、简单的、单向的服务器推送技术，是实现这种体验最自然、最高效、最可靠的技术选择。
它就像是为这个场景量身定做的工具，没有多余的功能，只有恰到好处的设计。因此，当 ChatGPT 等应用席卷全球时，其背后默默无闻的 SSE 技术也终于从幕后走到了台前，被广大开发者所重新认识和重视。
8、SSE的技术原理详解
8.1工作机制的流程图
SSE 通过一个持久的 HTTP 连接实现服务器到客户端的单向数据流。
以下是其工作机制的流程图：
以下是关键步骤解析。
1）浏览器发起一个 HTTP 请求，Header 中包含：
1Accept: text/event-stream
2）服务器响应类型必须为：
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive
3）服务器发送事件格式（每个事件以两个换行符结束）：
event: message
data: {"time": "2023-10-05T12:00:00", "value": "New update!"}
id: 12345
retry: 5000
\n\n
4）浏览器通过 EventSourceAPI 接收并处理事件。
5）服务器发送 一个特殊“结束”事件，可以结束传输。比如，服务器发送一个如 event: end 的消息，可以结束传输。客户端预先监听这个自定义的 end 事件，一旦收到，就知道传输结束，并可以选择主动关闭 EventSource 连接。
6）若连接中断，浏览器会根据 retry字段自动重连。如果没有收到 特殊“结束”事件， 浏览器 可以自动重连。
8.2SSE与其他通信方式对比
不同通信技术各有适用场景，我们用表格清晰对比：
8.3SSE的适用场景
1）ChatGPT 式逐字输出( “打字机” 式逐 词元 token输出)：
2）实时通知系统：
a. 新订单提醒；
b. 用户消息推送；
c. 审核状态更新。
3）实时数据看板：
a. 股票行情；
b. 设备监控数据；
c. 实时日志流。
12、选SSE还是选WebSocket？
12.1SSE与WebSocket全面对比
来对 Server-Sent Events (SSE) 和 WebSocket 进行一场全面、深入的对比。
为了更直观地理解两者的工作模式差异，请看下面的序列图：
1）协议与连接建立：
SSE 协议与连接建立：
a. 基于纯粹的 HTTP。客户端发起一个普通的 HTTP GET 请求，并携带特殊的头 Accept: text/event-stream。
b. 服务器响应后，保持这个 TCP 连接打开，并开始发送数据流 ，直到遇到结束标记。
c. 这是一种长连接的 HTTP 用法。
WebSocket 协议与连接建立：
a. 基于独立的 WebSocket 协议。连接始于一个特殊的 HTTP 请求，即 “协议升级”请求（Connection: Upgrade, Upgrade: websocket）。
b. 服务器响应 HTTP 101 Switching Protocols 后，最初的 HTTP 连接被替换为 WebSocket 连接，此后通信不再遵循 HTTP 协议，而是在其之上建立一个全双工的通道。
2）数据流与通信模式：
SSE：单向通信。设计初衷就是让服务器能够主动、高效地向客户端推送数据。•数据是文本流，格式简单且可读性强。每条消息可以附带一个事件类型（event:）和一个ID（id:）。•客户端使用 EventSource API 监听来自服务器的事件。
WebSocket：全双工通信。在连接建立后，客户端和服务器处于完全平等的地位，可以随时、任意地相互发送消息。 另外，WS协议 支持文本和二进制数据，灵活性极高，非常适合需要频繁双向交互的场景（如游戏、协作编辑）。
3）能力与特性：
SSE：内置自动重连机制。如果连接断开，EventSource 对象会自动尝试重新连接，并在重连后自动发送上一个收到的事件ID，服务器据此可判断错过了哪些消息，实现数据恢复。SSE有出色的浏览器支持。所有现代浏览器（Chrome, Firefox, Safari, Edge）都原生支持，Internet Explorer （古代浏览器）完全不支持（通常需要 polyfill 或降级方案）。
WebSocket：无自动重连。连接断开后，需要开发者手动编写重连逻辑和状态恢复逻辑。WS协议比SSE协议有更广泛的浏览器支持，包括 Internet Explorer 10+。
4）开发与集成：
SSE：开发与集成 非常简单。服务器端几乎不需要特殊的库，任何能输出 HTTP 流的后端语言都可以实现。客户端 API 也非常直观。与现有 HTTP 认证、CORS 机制完全兼容，处理方式与普通 HTTP 请求一致。
WebSocket：开发与集成 相对复杂。服务器端需要支持 WebSocket 协议的库（如 ws for Node.js, Socket.IO 等）。客户端需要处理连接状态、心跳包等。 虽然升级握手是 HTTP，但后续通信是独立协议，因此一些复杂的网络环境（如某些代理服务器）可能会带来问题。
12.2SSE与WebSocket到底该如何选择？
选择的关键在于应用场景和核心需求。
* 选择 SSE 的场景：
选择 SSE 的场景包括：
1）服务器到客户端的单向数据流。
2）简单和快速实现是关键因素。
3）需要自动错误恢复（重连）。
4）数据传输格式是文本（如 JSON），且不需要二进制。
SSE 典型的应用场景包括：
1）实时新闻推送、体育比分更新。
2）金融报价行情（如股票价格变动）。
3）社交媒体动态更新（如 Twitter 时间线）。
4）服务器日志流监控。
5）AI 处理进度或结果的流式输出。
* 选择 WebSocket 场景：
选择 WebSocket 的场景包括：
1）真正的实时双向通信，客户端和服务器都需要频繁地发送消息。
2）需要传输二进制数据（如视频、音频、图像碎片）。
3）构建交互性极强的应用，其中低延迟至关重要。
WebSocket 典型的应用场景包括：
1）实时在线聊天应用（如 Slack、Discord、RainbowChat-Web）。
2）多人在线游戏。
3）协同编辑工具（如 Google Docs）。
4）实时仪表盘和控制面板（需要双向控制）。
12.3WebSocket+SSE 混合架构
一般来说大型应用场景，强网用 WebSocket、弱网适合使用SSE ，这就是WebSocket+SSE 混合架构。强网用 WebSocket、弱网自动降级到 SSE 的混合架构， 核心在于网络质量动态评估和双通道无缝切换。
WebSocket+SSE 混合架构 具体实现方案如下：
12.4AI大模型中该选择SSE协议还是WebSocket？
直接答案：对于绝大多数 chat2ai 应用 优先选择 SSE (Server-Sent Events)。复杂的 chat2ai 应用 优先选择WebSocket。
但这并非绝对，我们需要根据具体的功能需求来决定。下面我将为你进行详细的分析和推理。
12.4.1）核心决策分析：
AI聊天应用的核心交互是：
1）客户端发送一条消息（一个问题）。
2）服务器接收后，调用大语言模型（LLM）API。
3）服务器将模型流式返回的答案（逐词或逐句）实时推送给客户端。
4）客户端实时渲染这个流式的答案，营造出“打字机”效果。
这个过程的关键在于第3步，即服务器向客户端的单向数据推送。这正是 SSE 的绝对主场。
12.4.2）为什么 SSE 是更优的选择？：
以下流程图清晰地展示了基于不同技术方案的聊天交互过程，其中突出了SSE方案的巨大优势：
AI大模型爆火的SSE技术到底是什么？万字长文，一篇读懂SSE！_22.png
正如上图所示：SSE 方案在实现上更加直接和高效，因为它基于 HTTP，并且专门为服务器到客户端的单向数据流设计。
此外，SSE 还带来了以下巨大优势：
1）开发复杂度极低：
a. 后端：你不需要引入任何复杂的 WebSocket 库（如 ws, Socket.IO）。你只需要建立一个普通的 HTTP 路由（如 POST /chat 用于发送消息，GET /chat/stream 用于接收流），并在控制器中输出 text/event-stream 格式的响应流。
b. 前端：使用浏览器原生的 EventSource API 即可轻松监听数据流，几行代码就能实现。无需实例化和管理 WebSocket 连接对象。
2）出色的兼容性与可维护性：
a. SSE 基于 HTTP，这意味着它更容易通过公司防火墙、代理，与现有的认证系统（如 Cookie、JWT）、CORS 策略协同工作，几乎不会遇到奇怪的网络问题。
b. 在浏览器“网络”选项卡中，SSE 的流清晰可见，易于调试。每个消息都是可读的文本，调试体验非常好。
3）内置的自动重连与断点续传机制：
a. 这是 SSE 的“杀手级特性”。网络连接不稳定是移动端的常见问题。如果用户在接收一个很长答案的过程中网络中断，SSE 会在网络恢复后自动重新连接。
b. 更强大的是，SSE 协议支持发送最后一个消息的 ID。服务器可以识别出这个 ID，并判断客户端错过了哪些数据，从而从断点处继续发送，而不是重新开始生成整个回答。这既节省了昂贵的 API 调用费用，也提升了用户体验。这在 WebSocket 中需要手动实现所有逻辑，非常复杂。
12.4.3）WebSocket 的适用场景：
虽然 SSE 是主流选择，但在 chat2ai 应用变得非常复杂时，WebSocket 可能会成为更好的选择。
在以下情况下， 应该考虑使用 WebSocket：
1）需要极高频的双向通信：不仅仅是用户提问->AI回答。例如：
a. 实时协作编辑：多个用户同时编辑一份由 AI 生成的文档，每个人的输入都需要实时同步给其他所有人。
b. AI多人游戏：基于 AI 生成剧情和环境的实时互动游戏，玩家的每一个动作都需要实时影响虚拟世界。
2）当需要传输二进制数据的时候：有的聊天应用不仅支持文本，还支持实时语音对话（客户端录音发送二进制音频流，服务器返回 AI 语音二进制流）。WebSocket 对二进制数据的支持是天生的。
3）你需要非常精确的控制心跳和连接状态： - WebSocket 允许 手动发送 Ping/Pong 帧来检测连接活性，虽然复杂，但给了开发人员最大的控制权。
12.4.4）传输协议选型 结论与建议：
1）起步和绝大多数情况：从 SSE 开始。这是最直接、最高效、最能给你带来稳定体验的选择。使用sse 遇到的技术挑战会更少，开发速度更快。ChatGPT、Claude 等绝大多数顶级应用都使用 SSE 不是没有道理的。
2）未来如果需要扩展：采用混合架构。如果应用未来需要加入上述 WebSocket 的适用功能（如实时语音），完全可以同时使用两种协议：使用 SSE 专门处理 AI 文本答案的流式推送。使用 WebSocket 专门处理 实时语音、实时协作等真正的双向通信功能。或者 强弱结合，自动切换。
因此，对于 chat2ai 的传输协议选型答案是：优先选择 SSE。
AI大模型爆火的SSE技术到底是什么？万字长文，一篇读懂SSE！_23.png
13、参考资料
[0] EventSource API Docs
[1] Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE
[2] SSE技术详解：一种全新的HTML5服务器推送事件技术
[3] 使用WebSocket和SSE技术实现Web端消息推送
[4] 详解Web端通信方式的演进：从Ajax、JSONP 到 SSE、Websocket
[5] 使用WebSocket和SSE技术实现Web端消息推送
[6] 一文读懂前端技术演进：盘点Web前端20年的技术变迁史
[7] WebSocket从入门到精通，半小时就够！
[8] 网页端IM通信技术快速入门：短轮询、长轮询、SSE、WebSocket
[9] 搞懂现代Web端即时通讯技术一文就够：WebSocket、socket.io、SSE
[10] 大模型时代多模型AI网关的架构设计与实现
[11] 全民AI时代，大模型客户端和服务端的实时通信到底用什么协议？
[12] 通俗易懂：AI大模型基于SSE的实时流式响应技术原理和实践示例
[13] Web端实时通信技术SSE在携程机票业务中的实践应用
[14] ChatGPT如何实现聊天一样的实时交互？快速读懂SSE实时“推”技术
