一、前言
Hello，欢迎来到流穿的AI探索之路系列专栏,作为一名AI应用工程师，我会在这儿更新一些前沿技术，欢迎关注哦。
这个问题也是前不久面试时被提问的，让我对比WebSocket和SSE，说说AI产品下处理SSE请求的方法。挺有意思就整理出来了
试想一个需求：
我们想实时了解某个数据，如果只用HTTP 协议，做不到服务器主动向客户端推送信息。只能是客户端向服务器发出轮询请求。
而轮询也存在问题：
服务端被迫维持大量不同的连接，以及由此造成的高开销
而随着LLM（大语言模型）的发展，流式的数据传输变得越来越普遍。两种常见的实时通信技术：WebSocket和SSE（Server-Sent Events） 也进入我们视野，为什么大语言模型对话不使用WebSocket而是SSE呢？
今天就来做一个对比
二、WebSocket概述 🌐
（一）WebSocket的工作原理 🔧
WebSocket 是一种全双工通信协议 🔄，可以在客户端和服务器之间建立持久连接。一旦连接建立，双方就可以在不需要再次握手的情况下，实时双向发送数据。
WebSocket是基于TCP/IP的，基于可靠性传输协议。处于OSI七层协议中的应用层。
下面一张图说明了 HTTP 与 WebSocket 的主要区别：
💡 可以看到WebSocket和Http是有联系的，WebSocket在建立握手时，数据是通过HTTP传输的。但是建立之后，在真正传输时候是不需要HTTP协议的。
1.通信过程 📡
(1). 连接建立：通过HTTP协议进行一次"握手"，升级到WebSocket协议。 (2). 数据传输：进行双向数据传输，即客户端可以向服务器发送请求，服务器也可以主动推送数据给客户端。 (3). 连接关闭：数据传输完成后，连接可以被主动关闭，减少资源消耗。
🔍 此处WebSocket打开连接后一直可以进行会话，而HTTP则需要不断的请求/响应
（二）WebSocket的原理
首先，WebSocket 作为持久化的协议，对比非持久的协议（HTTP 这种）。
HTTP 的生命周期通过 Request 来界定，也就是一个 Request 一个 Response。在 HTTP1.0 中，这次 HTTP 请求就结束了。
在 HTTP1.1 中进行了改进，使得有一个 keep-alive，也就是说，在一个 HTTP 连接中，可以发送多个 Request，接收多个 Response。但在 HTTP 中永远是 Request = Response，也就是说一个 Request 只能有一个 Response。而且这个 Response 也是被动的，不能主动发起。
GET /chat HTTP/1.1
Host: **.**.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key:
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://**.com
其中的 Upgrade 字段就会告诉服务器：要用 WebSocket 协议
浏览器也会对应返回：
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept:
Sec-WebSocket-Protocol: chat
告知客户端已使用 WebSocket
（三）、优缺点
1.优点：
- 双向通信 🔄：客户端和服务器可以同时发送和接收消息，实时互动更加灵活。
- 持久连接 🔗：一次握手建立连接后，可以维持长时间的连接，减少了频繁建立连接的开销。
- 低延迟 ⚡：适合高频率的实时数据交换，延迟较低。
2.缺点：
- 协议复杂性 🧩：相较于HTTP，WebSocket协议较为复杂，需要更多的实现细节来管理连接和数据交换。
- 浏览器支持 🌐：虽然大部分现代浏览器都支持WebSocket，但仍有部分旧版浏览器不兼容。
三、SSE概述 📡
（一）SSE的工作原理 🔧
Server-Sent Events (SSE) 是一种单向通信协议 🔀，允许服务器向客户端实时推送数据。与WebSocket不同，SSE是完全基于HTTP协议的，处于OSI七层协议中的应用层。
SSE的核心特点是服务器主动推送 🚀，客户端只需要建立一次连接，就可以持续接收服务器发送的消息，非常适合需要实时更新的场景。
下面这张图展示了SSE的基本工作流程：
💡 可以看到，SSE建立连接后，数据流是单向的，从服务器流向客户端。这与WebSocket的双向通信有所不同。
1.通信过程 📡
(1). 连接建立：客户端通过HTTP请求与服务器建立连接。
(2). 数据传输：服务器持续向客户端推送数据，客户端通过事件监听接收数据。
(3). 连接维护：SSE会自动尝试重新连接，如果连接断开。
🔍 注意SSE连接建立后，服务器可以持续推送数据，而不需要客户端重复发起请求。
（二）SSE的原理
SSE 利用 HTTP 协议的长连接特性，在客户端和服务器之间建立一个持久的连接。
当客户端发起一个SSE请求时，它会像这样：
GET /events HTTP/1.1
Host: example.com
Accept: text/event-stream
可以看到不同的是请求头里会设置text/event-stream
服务器接收到这个请求后，会返回一个特殊的响应：
HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alivedata: This is the first messagedata: This is the second messagedata: This is the third message
注意 Content-Type 被设置为 text/event-stream，这告诉浏览器我们正在使用SSE。
每条消息以 data: 开头，以两个换行符结束。服务器可以持续发送这样的消息，客户端会实时接收并处理。
（三）优缺点
1.优点：
- 简单易用 🍰：完全基于HTTP协议，实现和使用都相对简单。
- 自动重连 🔄：如果连接断开，SSE会自动尝试重新连接。
- 原生支持 🌈：现代浏览器原生支持SSE，无需额外库。
- 轻量级 🪶：相比WebSocket，SSE更加轻量，适合单向数据流场景。
2.缺点：
- 单向通信 👉：只能服务器向客户端推送数据，不支持客户端向服务器发送数据。
- 连接数限制 🚫：浏览器对同一个域名的SSE连接数有限制。
- 数据格式限制 📄：只能发送文本数据，二进制数据需要编码后传输。
四、为什么 LLM 选择 SSE？ 🎯
| 特性 | WebSocket | SSE |
|---|---|---|
| 通信方向 | 双向（全双工） | 单向（服务器到客户端） |
| 协议 | ws:// 或 wss:// | HTTP |
| 连接开销 | 较大 | 较小 |
| 自动重连 | 需要手动实现 | 原生支持 |
| 数据格式 | 支持文本和二进制 | 仅文本 |
| 最大连接数 | 受服务器限制 | 较高 |
| 跨域支持 | 需要特殊处理 | 简单，遵循 CORS |
(一) 符合场景需求
- LLM 生成文本是单向输出的过程（客户端提出问题后不需要在中途继续发送信息），无需双向通信
- 客户端主要是接收服务器生成的文本流
(二) 技术优势
- 更轻量级 💪
- 使用标准 HTTP 协议
- 不需要维护 WebSocket 连接状态，服务器资源消耗更少
- 更可靠 ✨
- 自动重连机制，断线重连无需额外代码
- 基于 HTTP 的可靠传输
(三) 资源效率
- 内存占用：SSE 比 WebSocket 更节省内存，因为：
- 不需要维护完整的 TCP 连接状态
- 使用 HTTP 的现有连接池
- CPU 使用：
- SSE 的解析开销更小
- 不需要处理 WebSocket 的帧控制