WebSocket vs SSE：实时通信技术的对比与选择

一、前言

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). 连接关闭：数据传输完成后，连接可以被主动关闭，减少资源消耗。

Tutorial-WebSocket-vs.-HTTP-communication-diagram

🔍 此处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__94">三、SSE概述 📡

SSE__96">（一）SSE的工作原理 🔧

Server-Sent Events (SSE) 是一种单向通信协议 🔀，允许服务器向客户端实时推送数据。与WebSocket不同，SSE是完全基于HTTP协议的，处于OSI七层协议中的应用层。

SSE的核心特点是服务器主动推送 🚀，客户端只需要建立一次连接，就可以持续接收服务器发送的消息，非常适合需要实时更新的场景。

下面这张图展示了SSE的基本工作流程：

images

💡 可以看到，SSE建立连接后，数据流是单向的，从服务器流向客户端。这与WebSocket的双向通信有所不同。

1.通信过程 📡

(1). 连接建立：客户端通过HTTP请求与服务器建立连接。

(2). 数据传输：服务器持续向客户端推送数据，客户端通过事件监听接收数据。

(3). 连接维护：SSE会自动尝试重新连接，如果连接断开。

🔍 注意SSE连接建立后，服务器可以持续推送数据，而不需要客户端重复发起请求。

SSE_124">（二）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连接数有限制。
数据格式限制 📄：只能发送文本数据，二进制数据需要编码后传输。

SSE__174">四、为什么 LLM 选择 SSE？ 🎯

特性	WebSocket	SSE
通信方向	双向（全双工）	单向（服务器到客户端）
协议	ws:// 或 wss://	HTTP
连接开销	较大	较小
自动重连	需要手动实现	原生支持
数据格式	支持文本和二进制	仅文本
最大连接数	受服务器限制	较高
跨域支持	需要特殊处理	简单，遵循 CORS

(一) 符合场景需求

LLM 生成文本是单向输出的过程（客户端提出问题后不需要在中途继续发送信息），无需双向通信
客户端主要是接收服务器生成的文本流

(二) 技术优势

更轻量级 💪
- 使用标准 HTTP 协议
- 不需要维护 WebSocket 连接状态，服务器资源消耗更少
更可靠 ✨
- 自动重连机制，断线重连无需额外代码
- 基于 HTTP 的可靠传输

(三) 资源效率

内存占用：SSE 比 WebSocket 更节省内存，因为：
- 不需要维护完整的 TCP 连接状态
- 使用 HTTP 的现有连接池
CPU 使用：
- SSE 的解析开销更小
- 不需要处理 WebSocket 的帧控制