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

一、背景：为什么我们离不开“实时通信”？

传统 Web 是典型的 Request/Response 模式：

浏览器有需求 → 发起 HTTP 请求 → 服务端返回结果 → 连接结束。

但现在的应用越来越“活”了：

• IM / 聊天系统：消息要秒级到达
• 实时监控大屏：指标曲线、日志流滚动刷新
• 在线协作：多人编辑文档、在线白板
• 播放/交易类：弹幕、订单状态、股票价格、盘口数据……

如果还用“有事我问你”的拉模式（轮询），要么延迟高，要么 HTTP 请求堆成山，服务端和网络都顶不住。

我们真正想要的是：

建立一条长期存在的通道，让服务器可以随时主动推送数据给客户端，甚至双方都能随时说话。

在这个诉求下，逐渐演化出：

• 基于 HTTP 的 SSE（Server-Sent Events）：单向服务器推送
• 基于独立协议的 WebSocket：全双工双向通信

很多人下结论：“WebSocket 更高级，SSE 是过时玩意”。
其实更准确的说法是：两者定位不同，是互补，而不是替代。

二、从轮询到长连接：问题是怎么一步步暴露出来的？

2.1 短轮询（Short Polling）

最原始方案：

setInterval(async () => {
const res = await fetch('/api/messages/latest');
const data = await res.json();
render(data);
}, 3000);

问题：

• 大量“空跑”请求：绝大多数时候是 “没新消息”

• 延迟 vs 压力的矛盾：

  • 想低延迟 → 间隔变短 → QPS 暴涨
  • 想省资源 → 间隔变长 → 延迟明显

2.2 长轮询（Long Polling / Comet）

改进版：一次请求挂久一点。

async function longPoll() {
try {
const res = await fetch('/api/messages/stream');
const data = await res.json();
render(data);
} finally {
// 无论成功失败，都紧接着再发下一次
longPoll();
}
}

longPoll();

服务端逻辑类似：

• 如果暂时没有消息，就挂起请求
• 有消息 / 超时再返回

长轮询减少了一部分空响应，但核心矛盾仍在：

• 还是要一次一次 HTTP 请求
• 每次都走完整 HTTP 头、路由、鉴权
• 中间代理有超时、最大连接数等限制

这时，自然会产生一个想法：

能不能建立一条真正的长连接，
让服务器想发就发，而不是“一个消息对应一个 HTTP 请求/响应”？

答案就是：SSE 和 WebSocket。

三、SSE：简单纯粹的服务器推送（Server-Sent Events）

3.1 定义与特点

SSE 全称 Server-Sent Events，由 HTML5 标准引入，特点：

• 完全基于 HTTP 协议，不需要额外的协议升级
• 连接方向是 单向：Server → Client
• 浏览器提供原生对象 EventSource
• 消息格式：text/event-stream 的文本流
• 内建自动重连和 Last-Event-ID 断点续传机制
• 实现成本低，适合简单的流式输出场景

非常适合：

• 实时日志流、监控指标、报警流
• 实时通知中心、站内信提醒
• 股票/榜单/业务指标刷榜

3.2 SSE 消息格式长什么样？

Content-Type: text/event-stream，每条消息由若干行组成，以空行结束：

id: 1001
event: notice
data: {"msg":"hello","level":"info"}

id: 1002
event: metrics
data: {"cpu":0.3,"mem":0.61}

: 这是注释行，浏览器不会触发事件

常用字段：

• id：事件 ID，浏览器断线重连时会给服务器带上 Last-Event-ID 头
• event：事件名，前端可以按事件类型做不同处理
• data：真正的数据内容，可以多行（会自动拼成一行）

3.3 前端：EventSource API 详解

const source = new EventSource('/sse/stream', {
withCredentials: true, // 是否携带 Cookie
});

// 连接状态：0-connecting，1-open，2-closed
console.log(source.readyState);

// 默认事件（event: message 或未指定 event）
source.onmessage = (event) => {
console.log('默认事件:', event.data);
const payload = JSON.parse(event.data);
render(payload);
};

// 自定义事件
source.addEventListener('notice', (event) => {
console.log('notice 事件:', event.data);
});

// 打开
source.onopen = () => {
console.log('SSE 连接已建立');
};

// 错误 & 断线（EventSource 会自动重连）
source.onerror = (err) => {
console.error('SSE 出错或断线:', err);
// 一般不建议这里自己重新 new EventSource
// 否则可能和浏览器内建重连冲突
};

// 主动关闭
function closeSSE() {
source.close();
}

几点注意：

3.4 服务端：Spring MVC 阻塞版示例

真实生产不推荐用阻塞循环，这里只是演示 SSE 格式。

@RestController
@RequestMapping("/sse")
public class SseController {

@GetMapping(value = "/stream", produces = "text/event-stream;charset=UTF-8")
public void stream(HttpServletResponse response) throws IOException {
response.setCharacterEncoding("UTF-8");
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Connection", "keep-alive");
response.setContentType("text/event-stream;charset=UTF-8");

PrintWriter writer = response.getWriter();

for (int i = 0; i < 10; i++) {
String data = "{\\"time\\":" + System.currentTimeMillis() + ",\\"value\\":" + i + "}";

writer.write("id: " + i + "\\n");
writer.write("event: metrics\\n");
writer.write("data: " + data + "\\n\\n");
writer.flush();

try {
Thread.sleep(1000);
} catch (InterruptedException ignored) {
}
}
}
}

3.5 服务端：Spring WebFlux / Reactor 版（推荐）

使用 WebFlux 可以更自然地返回一个无限流：

@RestController
@RequestMapping("/sse")
public class SseReactiveController {

@GetMapping(value = "/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux<ServerSentEvent<String>> stream() {
return Flux.interval(Duration.ofSeconds(1))
.map(seq -> ServerSentEvent.<String>builder()
.id(String.valueOf(seq))
.event("metrics")
.data("{\\"time\\":" + System.currentTimeMillis() + ",\\"value\\":" + seq + "}")
.build());
}
}

• MediaType.TEXT_EVENT_STREAM_VALUE 就是 text/event-stream
• Flux.interval 只是示例，真实场景通常是从 MQ / 内存通道 / 监控系统订阅数据源。

3.6 Last-Event-ID 与断点续传

当服务器为每条消息设置 id 字段时：

id: 42
event: metrics
data: {…}

浏览器断线重连时，会在请求头带上：

Last-Event-ID: 42

服务器可以据此：

• 从 ID 之后的消息继续推送（如果你有持久化）
• 或者记录用户上次消费位置，做类“消费位点”管理

这是很多人用 SSE 做“轻量日志/监控消费”的一个重要能力。

3.7 SSE 的优点整理

• 实现简单：HTTP + 文本流，框架 out-of-box
• 穿透性好：大部分代理/防火墙对 HTTP 长连接都较友好
• 自动重连：浏览器内建，不需要写复杂逻辑
• 天然适配流式场景：日志流、指标流、通知流

3.8 SSE 的局限性

• 单向：只能 Server → Client，Client → Server 仍需 HTTP 请求
• 不支持原生二进制：需要自己 base64 或其它编码
• 一些老旧环境兼容性略差（老 IE 等）
• 受限于反向代理 / 网关对 HTTP 长连接的配置（超时、并发连接数）

一句话概括：

如果你的需求是 “后端不停往前端推数据，前端很少主动发实时消息”，SSE 是非常优雅的选择。

四、WebSocket：为实时交互而生的全双工协议

4.1 协议与握手

WebSocket 依托 HTTP 做握手，然后升级为独立的 ws:// / wss:// 协议。

典型握手请求（浏览器→服务器）：

GET /ws/chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Sec-WebSocket-Protocol: chat, superchat
Origin: https://example.com

服务器响应：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

之后，两端就不再用 HTTP 报文，而是使用 WebSocket 帧进行通信。

特点：

• 通道是 全双工 的：任意时刻 Client/Server 都可以主动发送数据帧
• 支持文本帧、二进制帧、Ping/Pong、Close 等类型
• 一次握手、多次通信，头部开销几乎可以忽略

这使它成为 IM、游戏、协作等强交互场景的首选。

4.2 浏览器端 WebSocket API 详解

const ws = new WebSocket('wss://example.com/ws/chat?token=xxx');

// 连接打开
ws.onopen = () => {
console.log('WebSocket 打开');
// 连接建好后可以立刻发认证/加入房间消息
ws.send(JSON.stringify({
type: 'auth',
token: 'xxx',
}));
};

// 收到消息
ws.onmessage = (event) => {
// 可能是文本，也可能是二进制（取决于服务端）
const msg = JSON.parse(event.data);
handleMessage(msg);
};

// 连接关闭
ws.onclose = (event) => {
console.log('WebSocket 关闭', event.code, event.reason);
// 可在这里发起重连逻辑
};

// 错误
ws.onerror = (error) => {
console.error('WebSocket 错误: ', error);
};

// 封装一个简单发送函数
function sendMessage(payload) {
if (ws.readyState === WebSocket.OPEN) {
ws.send(JSON.stringify(payload));
} else {
console.warn('连接未就绪，消息被丢弃', payload);
}
}

几点实战注意：

• readyState：

  • 0：CONNECTING
  • 1：OPEN
  • 2：CLOSING
  • 3：CLOSED

• 可以通过 URL 参数、Header 或 Sec-WebSocket-Protocol 携带鉴权信息 / 版本号。

• 若网络不稳定，要自己实现 重连策略（指数退避、最大重试次数等）。

4.3 Spring Boot + STOMP 方案（适合业务系统）

配置：

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

@Override
public void registerStompEndpoints(StompEndpointRegistry registry) {
registry.addEndpoint("/ws")
.setAllowedOriginPatterns("*")
.withSockJS(); // 可选：提供降级（长轮询/iframe 等）
}

@Override
public void configureMessageBroker(MessageBrokerRegistry registry) {
registry.enableSimpleBroker("/topic", "/queue"); // 订阅前缀
registry.setApplicationDestinationPrefixes("/app"); // 客户端发送消息的目的前缀
}
}

消息处理：

@Controller
public class ChatController {

@MessageMapping("/chat.send") // 客户端发到 /app/chat.send
@SendTo("/topic/room") // 广播到订阅 /topic/room 的所有客户端
public ChatMessage send(ChatMessage message) {
message.setTimestamp(System.currentTimeMillis());
return message;
}
}

@Data
public class ChatMessage {
private String from;
private String content;
private long timestamp;
}

前端可以用 @stomp/stompjs / sockjs-client 等库进行连接订阅。

4.4 Netty 手写 WebSocket（适合你做 IM 网关）

简化版示例（仅演示关键 Handler）：

public class WebSocketServer {

public static void main(String[] args) throws InterruptedException {
EventLoopGroup boss = new NioEventLoopGroup(1);
EventLoopGroup worker = new NioEventLoopGroup();

try {
ServerBootstrap b = new ServerBootstrap();
b.group(boss, worker)
.channel(NioServerSocketChannel.class)
.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) {
ChannelPipeline p = ch.pipeline();
p.addLast(new HttpServerCodec());
p.addLast(new HttpObjectAggregator(65536));
p.addLast(new WebSocketServerProtocolHandler("/ws", null, true));
p.addLast(new SimpleChannelInboundHandler<TextWebSocketFrame>() {
@Override
protected void channelRead0(ChannelHandlerContext ctx, TextWebSocketFrame msg) {
String text = msg.text();
// TODO: 解 JSON、路由、广播、持久化…
ctx.writeAndFlush(new TextWebSocketFrame("echo: " + text));
}
});
}
});

Channel ch = b.bind(8080).sync().channel();
ch.closeFuture().sync();
} finally {
boss.shutdownGracefully();
worker.shutdownGracefully();
}
}
}

在真正的 IM / 网关场景，你会在此基础上：

• 增加连接认证（token / cookie）
• 建立 UserId → Channel 的映射
• 实现房间/群组的 ChannelGroup 管理
• 接入 MQ / RPC 与逻辑层、存储层交互

4.5 WebSocket 的优点总结

• 全双工：前端/后端都能随时主动发消息
• 支持二进制：适合音视频片段、protobuf、压缩格式
• 高频通信下头部开销极小
• 生态丰富：STOMP、Socket.io、自研协议都可以构建在其之上

4.6 WebSocket 的挑战

• 协议/部署复杂度高于 SSE

• 对代理 / 网关的配置要求更严（必须支持 Upgrade、keepalive 等）

• 需要自己设计：

  • 心跳 / 断线检测
  • 重连策略
  • 订阅模型 / 房间管理
  • 鉴权与授权（哪些用户能收哪些消息）

一句话概括：

如果你的项目是 IM、游戏、协同编辑、多终端实时协作，WebSocket 几乎是标配。

五、SSE vs WebSocket：多维度对比

5.1 快速对比表

5.2 性能与资源

两者都是长连接，本质压力主要来自：

• 并发连接数（File Descriptor / 线程 / EventLoop）
• 消息编解码 & 广播逻辑
• 下游服务瓶颈（数据库、MQ 等）

一般规律：

• 仅服务端推 → 客户端收的场景，SSE 足够且实现简单；

• 双向频繁通信、高并发场景，WebSocket 更合适；

• 真正的性能瓶颈往往不在协议，而在：

  • 架构设计（接入层 / 逻辑层 / 存储层）
  • 消息路由 & 广播算法
  • 有无合理限流、背压机制

5.3 网络环境与企业内网

• SSE 更像普通 HTTP 流，企业内代理、出口防火墙大多能容忍；
• WebSocket 要求代理支持 Upgrade，部分老设备/保守配置场景会“直接掐掉”，这时要么配置调整，要么降级到 SockJS / 长轮询。

在 ToB SaaS 场景（尤其连接各类甲方内网）时，这点非常关键。

六、真实项目中的选型：用什么、怎么用？

6.1 决策思路

可以简单套一个“选型决策树”：

6.2 场景示例

1）IM / 聊天 / 游戏大厅

• 客户端：不停发聊天消息、操作指令
• 服务端：推送群聊消息、在线列表、系统通知

👉 WebSocket 是主力，甚至你会做出一个“IM 接入层（Access）”作为独立服务。

2）监控大屏 / 日志中心

• 日志/监控系统往前端持续推流
• 前端只是查看，很少主动互动

👉 SSE 非常适合。配合 Kafka / Flink / TSDB 做后端数据源会很自然。

3）SaaS 管理后台 + 实时通知

• 90% 页面只是 CRUD / 报表 / 查询
• 偶尔会弹“有新工单”、“有新审批”、“有系统告警”

👉 两种实战方案：

• 早期：基于 SSE 做通知/告警推送，简单好维护；
• 后期：当你引入 WebSocket（比如在线客服、协同编辑）后，可以考虑统一抽一个“实时通道层”，通过一个 WebSocket 上 multiplex 多种消息类型。

七、统一消息协议 & 前端封装：减少未来返工

无论 SSE 还是 WebSocket，你都可以用同一套业务消息协议，后面切换/混用时几乎不改业务层。

7.1 建议的消息 Envelope

{
"type": "chat_message", // 消息类型
"version": 1, // 协议版本
"traceId": "xxx", // 可选：链路追踪
"payload": { // 业务内容
"from": "alice",
"to": "room-1",
"content": "hello"
}
}

好处：

• 避免“满世界 if/else 判断结构不同的 JSON”
• 方便做灰度 / 协议升级（version 字段非常关键）
• 可以在边车 / 网关层基于 type 做路由

7.2 前端统一封装：以 WebSocket 为例

class WSClient {
constructor(url, { autoReconnect = true, maxRetry = 10 } = {}) {
this.url = url;
this.autoReconnect = autoReconnect;
this.maxRetry = maxRetry;
this.retryCount = 0;
this.handlers = {};
this.connect();
}

connect() {
this.ws = new WebSocket(this.url);

this.ws.onopen = () => {
console.log('ws open');
this.retryCount = 0;
this.emit('open');
};

this.ws.onmessage = (evt) => {
try {
const msg = JSON.parse(evt.data);
this.emit(msg.type, msg);
} catch (e) {
console.error('parse msg error', e, evt.data);
}
};

this.ws.onclose = () => {
this.emit('close');
if (this.autoReconnect && this.retryCount < this.maxRetry) {
const delay = Math.min(30000, 1000 * Math.pow(2, this.retryCount));
this.retryCount++;
setTimeout(() => this.connect(), delay);
}
};

this.ws.onerror = (err) => {
this.emit('error', err);
};
}

send(type, payload) {
if (this.ws.readyState === WebSocket.OPEN) {
this.ws.send(JSON.stringify({ type, payload }));
}
}

on(type, handler) {
(this.handlers[type] = this.handlers[type] || []).push(handler);
}

emit(type, …args) {
(this.handlers[type] || []).forEach((h) => h(…args));
}

close() {
this.autoReconnect = false;
this.ws.close();
}
}

对于 SSE，也可以封一个 SSEClient，统一 on(type, handler) 风格，后端只是把 event: type 对上就行。

八、与 HTTP/2、gRPC、GraphQL Subscriptions 的关系（简要延伸）

现实中，你可能还会遇到这些名词：

• HTTP/2 server push：设计上有“推送”能力，但在浏览器中已基本被废弃（Chrome 也移除了支持）。
• gRPC streaming：基于 HTTP/2 的流式 RPC，更适合服务间通信，不是浏览器直连方案（除非 gRPC-Web）。
• GraphQL Subscriptions：常见实现底层多用 WebSocket 或 SSE，自身是“语义层”的协议。

可以简单记住：

浏览器层面，“实时”主要还是 SSE + WebSocket，两者是基础。
更高层方案（GraphQL Subscriptions、SignalR、Socket.io）往往只是封装 & 协议之上的抽象。

九、安全、运维与监控：上线后才是“真正的开始”

9.1 鉴权与授权

无论是 SSE 还是 WebSocket：

• 推荐用 短期 Token（JWT / 自研），而不是单纯依赖 Cookie Session；
• 对每个连接建立时进行认证，认证失败直接关闭；
• 对消息还要做授权校验（用户是否有权限订阅某房间/某数据流）。

WebSocket 鉴权策略举例：

9.2 连接数与限流

• 每个连接都占用 FD + 内存（缓冲区）：

  • 要设置连接数上限（按机器规格和业务模型）；
  • 对单 IP / 单用户的连接数做限流。

• 对消息发送：

  • 限制每秒消息数；
  • 对恶意/异常客户端进行断连或黑名单处理。

9.3 日志与监控指标

建议至少监控：

• 当前在线连接数（按节点、按用户类型）
• 每秒发送/接收消息数
• 鉴权失败次数、握手失败次数
• 断线重连频率（可用来判断网络质量/代理问题）

对于 SSE：

• 统计每条 SSE 连接的平均持续时间；
• 统计 Last-Event-ID 使用情况（是否频繁断线重连）。

十、常见坑与踩坑经验

10.1 SSE 被代理缓存 / 超时

• 忘了加 Cache-Control: no-cache，结果浏览器直接从缓存读，根本不走后端；
• 反向代理（Nginx、网关）默认有 proxy_read_timeout，时间一到就断连接 → 要配置足够长，或者前端/后端定期发心跳。

10.2 WebSocket 在 Nginx / 云原生环境下“莫名其妙断”

• 没有正确设置：

  • proxy_set_header Upgrade $http_upgrade;
  • proxy_set_header Connection "upgrade";

• 上游服务重启需要优雅处理断线 & 重连；

• Kubernetes / Service Mesh 中可能有额外的超时、连接数限制，需要逐层排查。

10.3 浏览器多 Tab 的处理

• 一个用户开 10 个 Tab，每个 Tab 开一个 WebSocket/SSE，后端就会有 10 条连接；

• 对于某些类型的通知流，可以：

  • 只允许一个“主 Tab”持有连接，其他 Tab 通过 BroadcastChannel / localStorage 事件接收消息；
  • 或者服务端按 userId 合并推送，前端自己决定如何展示。

10.4 重连风暴

• 服务端重启、网络抖动时，成千上万客户端同时重连；
• 需要前端采用 指数退避 + 随机抖动 的重连策略，避免连接雪崩。

十一、总结：正确使用“工具箱”，而不是迷信某个“银弹”

最后再强调一次本文想传达的观点：