SSE并非靠浏览器复用Keep-Alive连接，而是通过一次HTTP请求建立后服务端持续写入、永不关闭响应来实现单向长连接；Keep-Alive仅作为底层保障，防止中间设备过早断连，其作用是维持TCP连接空闲存活而非主动复用。
SSE（Server-Sent Events）本身不是靠浏览器主动复用 Keep-Alive 连接来维持长连接的，而是依赖 HTTP 持久连接（即 Keep-Alive）作为底层基础，再通过服务端持续不关闭响应流的方式实现单向长连接。它和“复用多个请求”无关，而是一次请求开启后，服务端不断写入数据、始终不结束响应——此时 Keep-Alive 的作用是：让这条 TCP 连接不被中间设备（如代理、负载均衡器、防火墙）或服务端自身过早断开。
换句话说：SSE 不是“反复发请求复用连接”，而是“发一个请求，然后一直不关响应”，Keep-Alive 是这条连接能活久一点的必要保障条件，不是主动机制。
SSE 如何与 Keep-Alive 协同工作
SSE 基于 HTTP/1.1，默认启用持久连接。只要服务端不发送 Connection: close，且响应头中包含 Content-Type: text/event-stream 和合适的缓存控制，浏览器就会保持连接打开，并持续接收数据块。
关键点在于：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 客户端只发起 一次 GET 请求；
- 服务端返回
200 OK，并持续写入事件流（event:、data:、id:、retry:），不调用 response.end() 或 close()； - 此时 TCP 连接若被空闲超时关闭，就不是 SSE 的问题，而是 Keep-Alive 配置或网络中间件干预的结果。
所以，“利用 Keep-Alive”实际是指：确保整条链路（客户端 → CDN/反代 → 应用服务器）都允许并维持该连接长期空闲存活。
服务端需配合的关键配置（以常见环境为例）
-
Node.js（Express）
需禁用默认的响应超时，并设置合适的响应头：res.writeHead(200, { 'Content-Type': 'text/event-stream', 'Cache-Control': 'no-cache', 'Connection': 'keep-alive', // 显式声明（虽 HTTP/1.1 默认，但显式更稳妥） 'X-Accel-Buffering': 'no' // Nginx 专用，禁用缓冲 }); // 保持连接不结束，定期发送 :keep-alive 注释防超时 const keepAlive = setInterval(() => { res.write(': keep-alive\n\n'); }, 45_000); // 小于服务端 timeout（如 60s） -
Nginx 反向代理场景（最常见断连原因）
默认proxy_read_timeout是 60 秒，空闲超过即断连。必须显式延长：location /events { proxy_pass http://backend; proxy_cache_off; proxy_buffering off; proxy_http_version 1.1; proxy_set_header Connection 'keep-alive'; proxy_set_header X-Forwarded-For $remote_addr; proxy_read_timeout 300; # 至少 5 分钟 proxy_send_timeout 300; # 关键：透传 Connection 和 Transfer-Encoding proxy_ignore_client_abort off; } -
Apache / Tomcat / Spring Boot 等
同样需检查：- 服务端
KeepAliveTimeout（如 Apache 默认仅 5–15 秒，需设为 ≥300）； - 应用容器是否启用了连接池自动回收空闲连接（如 Tomcat 的
connectionTimeout和keepAliveTimeout）； - Spring Boot 中可通过
server.tomcat.connection-timeout=-1（禁用超时）或设为较大值。
- 服务端
浏览器侧无需额外操作，但要注意
-
EventSource构造函数会自动使用持久连接，无需手动加Connection: keep-alive； - 若连接意外断开，浏览器自动重连（遵循
retry:字段或默认 3 秒），这是 SSE 内置行为； - 不要手动调用
eventSource.close()，除非明确要终止； - 避免在响应中写入
Content-Length—— SSE 是流式响应，必须用Transfer-Encoding: chunked（由服务端自动处理）。
常见断连原因及应对（非代码逻辑问题，而是 Keep-Alive 失效）
- ✅ 服务端
KeepAliveTimeout太短（如 Apache 默认 5s）→ 调大至 300s+ - ✅ 中间代理（Nginx / Cloudflare / ALB）空闲超时更短 → 优先调高
proxy_read_timeout - ✅ CDN 或防火墙主动 kill 空闲连接（尤其企业网络）→ 加
:keep-alive注释保活 - ✅ 客户端休眠/锁屏导致系统级连接中断（移动端常见）→ 依赖浏览器自动重连，服务端支持
Last-Event-ID断点续传
SSE 的“长久维持”本质是服务端持续输出 + 全链路容忍长空闲，Keep-Alive 不是它主动使用的技巧，而是它赖以生存的基础设施守则。真正起作用的是服务端不结束响应、中间件不切断空闲连接、客户端不主动关闭——三者缺一不可。
