SSE

一、SSE与WebSocket有什么区别？

1. 通信方向差异

SSE 是单向通信协议，仅支持服务器向客户端推送数据，客户端无法通过同一连接向服务器发送消息，如需上传数据需额外发起HTTP请求。WebSocket 是双向全双工协议，客户端和服务器在任何时候都可以互相发送数据，适合在线聊天、多人协作等双向交互场景。

2. 协议底层差异

SSE构建在标准HTTP/HTTPS协议之上，无需协议升级，兼容所有现有网络基础设施（负载均衡器、CDN、代理服务器等）。WebSocket 需要先通过HTTP Upgrade握手升级为专用的WebSocket协议（ws://或wss://），部分严格的公司代理或防火墙可能会拦截Upgrade请求导致连接失败。

3. 数据格式差异

SSE 仅支持UTF-8编码的文本数据传输，消息格式由W3C规范严格定义（data:、event:、id:、retry:字段）。WebSocket 支持文本和二进制数据帧，可传输图片、文件、音视频流等二进制内容，数据格式由应用层自行定义。

4. 重连机制差异

SSE 在浏览器端内置了自动重连机制，连接断开后浏览器会自动尝试重新连接，并可通过Last-Event-ID请求头实现断线期间的消息续传，开发者无需编写重连代码。WebSocket没有内置重连机制，需要开发者手动实现心跳检测、重连逻辑和消息重发策略。

5. 浏览器连接数限制

在HTTP/1.1环境下，浏览器对同一域名的并发HTTP连接数有限制（通常为6个），每个SSE连接会占用一个连接槽位。WebSocket连接不占用HTTP连接限额，更适合需要大量并发连接的场景。HTTP/2环境下该限制已大幅缓解，多个SSE流可复用同一TCP连接。

二、SSE的工作原理是什么？

1. 连接建立流程

客户端通过JavaScript创建EventSource对象并指定服务端SSE端点URL，浏览器随即发起一个标准的HTTP GET请求，请求头中包含Accept: text/event-stream。服务器响应状态200 OK，响应头中包含Content-Type: text/event-stream、Cache-Control: no-cache、Connection: keep-alive，然后保持连接打开，开始持续写入事件数据。

2. 事件流数据格式

SSE 协议定义了严格的文本格式：每条消息由一个或多个字段行组成，字段行格式为字段名: 字段值\n，消息之间用空行（\n\n）分隔。常用字段包括：data:消息负载（可多行，多行data会自动拼接）、event:自定义事件类型、id:消息ID（用于重连时标识最后接收的消息）、retry:建议的重连等待时间（毫秒）、:开头的行为注释行（常用于心跳保活）。

3. 自动重连机制

当SSE连接因网络故障、服务器重启等原因断开时，浏览器内置的EventSource 会自动尝试重新连接，默认等待3秒后重试，等待时间可通过服务器下发的retry:字段调整。重连时浏览器会自动在HTTP请求头中携带Last-Event-ID字段，值为最后一次收到的消息ID，服务器可据此补发断线期间遗漏的消息。

4. HTTP/2环境下的优化

在HTTP/2协议下，多个SSE连接可复用同一个TCP连接（多路复用），有效规避了HTTP/1.1的6连接并发限制。腾讯云CLB（负载均衡器）和腾讯云CDN均已支持HTTP/2，在实际部署中建议优先使用HTTP/2或HTTP/3以降低连接开销。

三、SSE有哪些技术特点？

1. 基于标准HTTP协议

SSE 完全构建在HTTP/HTTPS协议之上，无需引入额外协议支持，可无缝穿过企业防火墙、代理服务器和CDN ，部署成本远低于WebSocket。在腾讯云等云平台上，SSE 可直接通过负载均衡CLB 、API网关等标准HTTP服务转发，无需额外配置协议升级。

2. 内置自动重连与消息续传

浏览器原生支持断线自动重连，并通过Last-Event-ID机制支持消息续传，确保网络短暂中断后不丢失数据。该能力由浏览器内核实现，开发者无需自行编写重连和消息缓存逻辑，显著降低了客户端代码复杂度。

3. 轻量级的资源消耗

与WebSocket 相比，SSE在服务端不需要维护复杂的连接状态和帧解析逻辑，单个连接的内存占用通常为1-5KB，而WebSocket连接通常需要2-10KB。对于仅需服务器推送的场景，SSE 能以更少的服务器资源支撑更多并发连接。

4. 支持自定义事件类型

SSE 允许服务器通过event:字段定义不同的事件类型，客户端可通过addEventListener()针对不同类型的事件注册独立的处理函数，实现消息的精细化路由处理，而无需在消息体内定义事件类型并在客户端手动判断。

5. 仅支持文本数据传输

SSE协议设计上仅支持UTF-8编码的文本数据，不支持二进制数据传输。如果需要推送图片、文件等二进制内容，需先进行Base64编码（会增加约33%的数据体积），或改用WebSocket 协议。对于JSON、纯文本、AI模型流式输出等场景，SSE的文本传输模式完全满足需求。

四、SSE如何处理重连机制？

1. 浏览器内置自动重连

EventSource API在连接非正常关闭时会自动发起重连，无需开发者编写任何重连代码。默认重连间隔为3000毫秒（3秒），该值由浏览器实现决定，部分浏览器可能使用不同默认值。

2. 服务器控制重连间隔

服务器可在事件流中随时下发retry:字段（值为毫秒数），浏览器收到后会将该值作为后续重连的等待时间。例如retry: 10000\n\n告知浏览器10秒后再尝试重连，适用于服务器即将重启、希望客户端延迟重连以减少无效连接请求的场景。

3. Last-Event-ID消息续传

每条SSE消息可携带id:字段，浏览器会自动记录最后一次成功接收的消息ID。重连时浏览器会在HTTP请求头中自动附带Last-Event-ID: <最后收到的ID>，服务器收到后可查询该ID之后的新消息并补发给客户端，实现"至少一次"的消息传递保证。

4. 客户端主动控制重连

开发者可通过eventSource.close()主动关闭连接，此时浏览器不会再自动重连。如需实现自定义重连策略（如指数退避、最大重试次数限制），可在onerror回调中主动关闭EventSource并自行控制重连节奏，而非依赖浏览器默认行为。

五、SSE在哪些场景下适用？

1. AI/大模型流式输出

SSE是AI对话类产品流式输出的主流技术方案。OpenAI、Anthropic Claude、腾讯云等厂商的对话API均使用SSE协议实现逐字输出效果。服务端在模型生成每个token后即可通过SSE 推送到客户端，用户无需等待完整回复生成完毕即可开始阅读，显著降低了感知延迟。

2. 实时通知与消息推送

新闻推送、邮件提醒、订单状态更新、系统公告等场景仅需服务器向客户端单向推送数据，SSE能以最低的复杂度实现实时通知能力。相比WebSocket ，SSE无需维护双向通信状态，服务端可基于消息队列（如腾讯云CMQ/CKafka） broadcast消息给所有在线连接。

3. 实时数据监控与仪表盘

股票行情、加密货币价格、服务器运维监控指标、IoT传感器数据等需要持续刷新显示的场景，SSE 能以最小的服务端开销实现数据实时刷新。

4. 任务进度与构建日志流式推送

文件处理、视频转码、CI/CD构建等耗时任务的进度更新，可通过SSE将进度百分比、日志行等实时推送到前端页面，用户无需手动刷新即可看到任务执行状态。

5. 不适合使用SSE的场景

需要客户端频繁向服务器发送数据的场景（如在线多人聊天、实时协作编辑）应使用WebSocket 。需要传输二进制数据（如音视频流、文件上传进度）的场景也应选择WebSocket。对IE浏览器的兼容性有严格要求的项目需注意：IE全版本均不支持EventSource，需使用polyfill库兜底。

六、SSE在服务端如何实现？

1. Node.js（Express）实现

在Express框架中，SSE端点的核心步骤为：设置响应头Content-Type: text/event-stream、Cache-Control: no-cache、Connection: keep-alive；然后在一个循环中周期性地调用res.write()写入符合SSE格式的文本，并以\n\n结束每条消息；客户端断开时监听req.on('close')事件清理定时器或资源。注意每个res.write()调用后建议显式调用res.flush()（若获取到了Flusher）以确保数据立即发送到网络。

2. Python（FastAPI/Flask）实现

FastAPI生态中推荐使用sse-starlette库，它提供了符合W3C规范的EventSourceResponse响应类，支持异步生成器作为事件源，并内置了连接管理和优雅关闭能力。Flask生态中可通过Response配合stream_with_context实现，设置mimetype='text/event-stream'及对应的头部即可。使用腾讯云函数（SCF）等Serverless服务时需注意：函数默认执行超时时间较短，SSE长连接需将超时时间调大或使用层（Layer）方案保持连接。

3. Go语言实现

Go标准库的net/http包天然支持SSE实现：通过类型断言获取http.Flusher接口并调用Flush()方法确保每次写入立即发送；配合goroutine可为每个SSE连接启动独立的后台推送协程。在腾讯云TKE（容器服务）中部署时，需注意Pod的优雅退出信号处理，确保SSE连接在Pod缩容时被正确关闭并触发客户端重连。

4. Java（Spring Boot）实现

Spring Boot 提供了两种SSE实现路径：SseEmitter（基于Servlet栈，适合传统Spring MVC项目）和Flux<ServerSentEvent>（基于Spring WebFlux反应式栈，适合高并发场景）。使用SseEmitter时需注意设置超时时间（setTimeout()），超时后连接会自动关闭并由浏览器重连；使用WebFlux时可直接返回Flux数据流，框架会自动处理HTTP响应头和流式写入。

5. 服务端实现的关键注意点

每条SSE消息必须以\n\n（两个换行符）结尾，仅以一个\n结尾的消息不会被浏览器解析。对于Nginx等反向代理，必须关闭代理缓冲（proxy_buffering off），否则Nginx会缓存响应体达到一定大小后才转发给客户端，导致消息延迟。如使用腾讯云CLB做负载均衡，需将CLB的空闲超时时间调大（默认可能为60秒），避免长连接被提前断开。

七、SSE有哪些开源库或框架支持？

1. JavaScript/TypeScript生态

better-sse是一个零依赖、符合W3C规范的TypeScript SSE服务端库，支持Express、Hono、Fastify、NestJS、Next.js等所有主流Node.js框架，内置了频道广播、事件缓冲、可配置的重连时间、数据序列化等功能。对于需要EventSource polyfill的场景（如IE浏览器或React Native），可使用event-source-polyfill或eventsource-polyfill库，它们提供了与标准EventSource兼容的API实现。

2. Python生态

sse-starlette是专为Starlette和FastAPI设计的生产级SSE 库，支持异步生成器、多线程安全、多事件循环场景，当前最新版本为3.4.5（2026年6月发布）。fastapi-sse-events则提供了基于Redis Pub/Sub的SSE事件广播能力，适合多实例部署场景下的事件分发，解决了单机内存中保存连接列表无法跨实例广播的问题。

3. Go生态

gin-contrib/sse是Gin框架的官方SSE中间件，提供了简洁的API来发送SSE事件。对于标准库net/http用户，可直接使用http.Flusher接口实现，无需额外依赖。在微服务场景下，可结合腾讯云CMQ或CKafka等消息队列，实现跨服务的事件广播。

4. Java生态

Spring Boot 的SseEmitter和WebFlux的ServerSentEvent类均为框架内置支持，无需额外依赖。对于非Spring 项目，可使用Java EE的Servlet 3.1+异步上下文（AsyncContext）配合ServletResponse.getWriter()实现SSE推送。

5. 跨端/多平台客户端工具

sse-kit是一个多平台SSE客户端工具包，支持Web（H5）、微信小程序、百度小程序、React Native 等环境，提供了完整的TypeScript类型定义和统一的API接口，解决了小程序环境不支持原生EventSource的问题。在腾讯云开发（TCB）等小程序后端云服务中，可结合云函数HTTP触发器与sse-kit实现小程序的实时推送能力。

八、SSE如何处理跨域问题（CORS）？

1. 同源策略限制

浏览器默认遵循同源策略（Same-Origin Policy），EventSource对象只能连接与页面同源（协议、域名、端口均相同）的SSE端点，跨域请求会被浏览器直接拦截。与普通AJAX请求不同，EventSource不支持通过设置请求头的方式绕过同源限制，必须依赖服务器的CORS配置。

2. 服务端CORS响应头配置

服务器需在SSE 端点的HTTP响应头中添加Access-Control-Allow-Origin字段，将其设为允许的来源（如https://www.example.com）或*（允许所有来源，不推荐在生产环境中使用）。如需携带Cookie或HTTP认证信息，还需添加Access-Control-Allow-Credentials: true，同时注意：当该字段为true时，Access-Control-Allow-Origin不能设为*，必须明确指定允许的来源。

3. 客户端withCredentials配置

当SSE请求需要携带Cookie（如基于会话的认证）时，客户端创建EventSource对象需传入第二个参数：new EventSource(url, { withCredentials: true })。该配置会使浏览器在SSE请求中自动附带当前域下的Cookie，服务器据此可进行会话验证和权限控制。

4. 预检请求（Preflight）处理

标准的EventSource请求使用GET方法且不带自定义请求头，通常不会触发浏览器的CORS预检请求（OPTIONS）。但如果服务端对SSE端点添加了自定义认证头（如通过URL Query参数传递Token的除外方案），则需注意处理OPTIONS请求。大多数Web框架（如Express、Spring Boot ）的CORS中间件已自动处理了预检请求，开发者只需正确配置允许的HTTP方法和请求头即可。

九、SSE如何保证消息的可靠性传递？

1. Last-Event-ID续传机制

SSE协议通过id:字段和Last-Event-ID请求头实现消息续传。服务端为每条消息分配单调递增或全局唯一的ID，客户端重连时自动在请求头中携带最后收到的消息ID，服务端据此查询并补发遗漏的消息。该机制依赖服务端保存最近N条消息的缓冲区或持久化存储（如Redis 、数据库），缓冲区大小需根据业务消息产生速率和可能的断线时长合理设置。

2. "至少一次"传递语义

在SSE协议本身不提供消息确认（ACK）机制的前提下，通过Last-Event-ID续传可实现"至少一次"（At-Least-Once）的消息传递保证：正常情况下每条消息恰好传递一次；网络断开并重连后，可能重复收到断线前的最后几条消息（因客户端最后收到的ID对应的消息可能已被处理，但服务器无法精确感知）。业务层需对消息处理做幂等性设计，确保重复消息不会导致异常状态。

3. TCP传输层可靠性

SSE基于TCP协议传输，TCP本身提供了数据有序、无损坏、无丢失的字节流传输保证。在TCP连接正常的前提下，服务端写入的SSE消息会完整、按序地到达客户端。但需注意：当TCP连接非正常关闭（如进程崩溃、网络中断）时，已在TCP发送缓冲区中但尚未被对端确认的数据会丢失，这部分消息需要通过Last-Event-ID机制补发。

4. 服务端消息缓冲区管理

为保证重连期间的消息不丢失，服务端通常需要在内存中维护一个按消息ID排序的缓冲区（如环形缓冲区或链表），保存最近N条消息。缓冲区大小需要在消息可靠性与内存占用之间权衡：过大的缓冲区会增加内存压力，过小的缓冲区可能导致重连时间跨度较大时无法完整补发遗漏消息。在生产环境中，可结合腾讯云Redis等外部存储来持久化消息ID与内容，支持更长时间跨度的重连补发。

十、SSE在移动端的兼容性如何？

1. 浏览器环境兼容性

现代移动浏览器对SSE的支持较为完善：Chrome for Android（2012年起，版本18+）、Safari on iOS（2011年起，版本5+）均已原生支持EventSource API。Android WebView（2013年起，版本4.4+）和iOS WKWebView中也可正常使用SSE。唯一的显著例外是Internet Explorer（全版本均不支持），但在移动端IE已基本绝迹，实际影响可忽略。

2. 微信小程序/百度小程序环境

微信小程序、百度智能小程序等平台的环境中不提供原生的EventSource对象，无法直接通过标准API使用SSE。解决方案包括：使用Taro.request等分块传输能力模拟SSE协议并增量解析响应体；或通过XMLHttpRequest的onprogress事件累积响应文本并自行解析SSE格式；也有开源库如sse-kit提供了跨端统一的SSE客户端封装，可在小程序环境中使用。

3. React Native / uni-app等跨端框架

React Native 的fetchAPI在iOS上不支持流式Response（response.body为null），无法直接解析SSE流。社区中通常使用react-native-sse等第三方库，或通过XMLHttpRequest的onprogress事件自行实现SSE解析器。uni-app环境中可使用其提供的统一网络请求API，配合平台判断分别实现H5端的原生EventSource 和小程序端的模拟实现。

4. 移动端网络特性考量

移动设备经常在不同网络之间切换（Wi-Fi与蜂窝网络互切），或遇到信号弱导致TCP连接中断的情况。SSE的自动重连机制在这种情况下表现良好：连接断开后浏览器会自动重连并携带Last-Event-ID，用户通常无需手动干预。在移动端使用SSE时，建议服务器设置合理的retry:值（如10000毫秒），避免在网络短暂抖动时过于频繁地重连。

十一、SSE如何处理网络中断和自动重连？

1. 浏览器自动重连流程

当SSE 连接因网络中断、服务器进程退出、负载均衡器超时等原因断开时，浏览器会自动执行重连流程：首先关闭当前EventSource连接，等待retry:指定的毫秒数（默认约3000毫秒），然后自动重新发起HTTP GET请求到原始SSE端点URL，并在请求头中附带Last-Event-ID字段。该流程会持续进行，直到连接成功建立或开发者主动调用eventSource.close()。

2. 服务器主动控制重连行为

服务器可通过在事件流中下发retry: <毫秒数>\n\n来动态控制客户端的重连等待时间。例如在服务器即将重启前，可先向所有在线客户端下发retry: 30000\n\n，告知客户端30秒后再重连，从而避免在服务器重启期间产生大量无效的重连请求。也可针对不同网络质量的客户端下发不同的重连间隔，优化整体重连流量。

3. 网络分区与长时间静默的处理

在SSE 长连接长时间没有数据推送的情况下，中间网络设备（如NAT网关、运营商级NAT）可能会认为连接已空闲而主动关闭TCP连接。解决方案是服务器定期发送心跳消息（通常是一条注释行，如: heartbeat\n\n，以:开头的行被协议定义为注释，不会被客户端当作消息处理，但会触发HTTP层的数据发送，从而保持TCP连接活跃）。

4. 客户端自定义重连策略

虽然浏览器提供了内置自动重连，但在某些场景下开发者需要更精细的控制：如限制最大重连次数、采用指数退避算法避免雪崩、在网络从离线恢复后立即触发重连等。实现方式为：监听EventSource的onerror事件，在回调中主动调用eventSource.close()关闭当前连接，然后自行通过setTimeout控制重连节奏并创建新的EventSource对象。

十二、SSE在微服务架构中如何应用？

1. 微服务中的SSE连接管理挑战

在微服务架构下，SSE长连接通常终止于网关层（如腾讯云API网关、Kong、Nginx ），或由专门的推送服务统一管理。如果每个微服务实例都直接维护SSE连接，当该实例下线或扩容时，连接到该实例的用户会全部断线并重连，造成较大的重连风暴。推荐方案是将SSE连接管理抽离为独立的推送服务（Push Service），其他微服务通过消息队列或gRPC向推送服务发送事件，由推送服务统一负责向在线客户端广播。

2. 结合消息队列实现事件广播

典型的微服务SSE架构为：多个业务微服务将需要推送的事件发布到消息队列（如腾讯云CMQ、CKafka 、RabbitMQ ），SSE推送服务消费这些队列中的消息，并通过内存中的连接映射表将消息推送到对应的客户端SSE连接。该方案实现了业务处理逻辑与连接管理的解耦，且支持推送服务的水平扩展（通过按用户ID哈希分片连接到不同推送服务实例）。

3. 服务发现与负载均衡考量

当SSE推送服务需要水平扩展时，客户端的SSE连接会分散到多个推送服务实例上。如果业务服务需要向特定用户推送消息，需要一种机制来确定该用户的SSE连接当前由哪个推送服务实例持有。常见解决方案包括：使用Redis等分布式KV存储记录用户ID到推送服务实例地址的映射；或使用腾讯云CMQ等消息队列的广播/订阅能力，让所有推送服务实例都收到消息后各自判断是否需要处理。

4. Kubernetes环境中的部署要点

在腾讯云TKE等Kubernetes环境中部署SSE推送服务时，需注意：Pod缩容或滚动更新会导致该Pod上的SSE连接全部断开，需确保客户端有自动重连机制；可使用Pod的preStop钩子，在Pod退出前等待足够长时间（如30秒），让客户端重连到其他Pod；Ingress Controller（如Nginx Ingress）需配置足够大的代理读取超时（proxy-read-timeout），避免正常但空闲的SSE连接被Ingress主动断开。

十三、SSE有哪些安全性考虑？

1. 身份认证与授权

EventSource API不支持在请求头中设置自定义字段（如Authorization: Bearer <token>），因此SSE 端点的认证通常通过以下方式实现：将认证Token作为URL Query参数传递（需注意URL可能被记录在访问日志中，应使用短有效期的一次性Token）；或依赖Cookie-Based认证（浏览器会自动在请求中附带Cookie）。更安全的方案是：客户端先通过普通HTTP POST接口获取一个短期有效的SSE专用Token，再将该Token作为Query 参数传入SSE端点URL。

2. HTTPS加密传输

SSE 传输的内容应通过HTTPS加密，防止中间人攻击窃听推送内容或注入恶意消息。具体做法是将SSE端点部署为HTTPS地址（而非HTTP），确保整条数据链路处于TLS加密保护之下。特别是在公共Wi-Fi环境下，未加密的SSE连接存在较大安全风险。腾讯云CLB和API网关均支持一键开启HTTPS监听，配合SSL证书可快速实现SSE传输加密。

3. 连接数与资源消耗防护

SSE 长连接会持续占用服务器资源，恶意客户端可创建大量SSE连接消耗服务器TCP端口和内存资源，造成拒绝服务（DoS）攻击。防护措施包括：在网关层（如腾讯云WAF）限制单IP可建立的并发SSE连接数；要求SSE连接建立前必须通过身份认证，仅允许已登录用户建立SSE连接；设置每个用户的最大SSE连接数（通常为1-3个）。

4. Token泄露与重放攻击防护

当使用URL Query参数传递认证Token时，Token可能出现在浏览器地址栏、服务器访问日志、Referer请求头等位置，存在泄露风险。防护措施包括：使用短期有效的单次Token（Token被使用后即失效）；在Token中嵌入客户端IP、User-Agent等指纹信息，服务端验证Token时核对指纹；使用腾讯云WAF等Web应用防火墙识别和拦截异常的SSE连接请求模式。

十四、SSE如何与Nginx、Apache等Web服务器配合使用？

1. Nginx反向代理核心配置

Nginx 作为SSE的反向代理时，最关键的是关闭代理响应缓冲（proxy_buffering off），否则Nginx 会将后端推送的消息缓存到缓冲区达到一定大小后才转发给客户端，严重破坏实时性。完整的关键配置包括：proxy_buffering off;、proxy_cache off;、gzip off;（禁用压缩，压缩会破坏SSE 流的实时解析）、proxy_read_timeout 3600s;（设置足够大的读取超时，避免空闲连接被Nginx主动断开）、proxy_http_version 1.1;、proxy_set_header Connection "";（确保使用HTTP/1.1长连接）。

2. Apache服务器配置

Apache 作为SSE反向代理时，需启用mod_proxy和mod_proxy_http模块，并在配置中设置ProxyPass的超时参数：ProxyPass /events http://backend:3000/events connectiontimeout=3600（设置足够大的连接超时）。同时需关闭mod_deflate压缩模块对SSE路径的压缩，并确保EventSource请求不经过任何会缓存响应的中间件。

3. CDN层面的注意事项

部分CDN 服务会在边缘节点缓存HTTP响应，而SSE端点返回的是无限长的text/event-stream流，不应被CDN缓存。需确保SSE端点的HTTP响应头中包含Cache-Control: no-cache, no-store, must-revalidate，并告知CDN不要缓存该路径的响应。腾讯云CDN支持基于URL路径的缓存规则配置，可将SSE端点路径（如/api/stream、/events）设置为不缓存。

4. 多层代理环境下的的问题排查

在"客户端 → CDN → 负载均衡器（如腾讯云CLB）→ Nginx → 应用服务器"的多层代理架构中，任何一层未正确关闭缓冲或设置了过短的超时，都会导致SSE流中断或延迟。排查方法：使用curl -N（禁用缓冲）直接访问应用服务器SSE端口，观察消息是否实时到达；然后逐层向前，在每一层代理后使用curl测试，定位哪一层引入了延迟或断开问题。

十五、SSE与长轮询（Long Polling）相比有什么优势？

1. 实时性差异

SSE 在服务器有新数据时立即推送，延迟通常仅为网络RTT（往返时间）级别（几毫秒到几十毫秒）。长轮询虽然也将服务器响应保持打开一段时间，但每次消息推送完成后客户端仍需重新发起请求，引入了额外的请求建立延迟；且如果服务器端在保持期间没有新数据，请求会因超时返回空响应，进一步增加消息传递延迟。

2. 服务器资源消耗差异

SSE为每个客户端维持一个长期HTTP连接，连接建立后的每次消息推送仅需写入响应体，开销极小。长轮询则需要为每个客户端周期性地建立HTTP连接、执行服务端处理逻辑、返回响应、然后关闭连接，在高并发场景下会显著增加服务器CPU和数据库连接池的压力。对于消息频率较低的应用，长轮询的部分请求会空等超时，造成资源浪费。

3. 客户端实现复杂度差异

SSE的客户端实现极为简单：创建一个EventSource 对象，注册onmessage或addEventListener回调即可，浏览器自动处理重连、Last-Event-ID续传等复杂逻辑。长轮询的客户端则需要自行实现：发起AJAX请求、处理响应、立即或等待一小段时间后再次发起请求、处理请求失败和超时、实现退避重连策略等，代码复杂度明显更高。

4. 网络友好性差异

SSE复用单一HTTP长连接，减少了TCP握手、SSL握手的频次，对网络基础设施更友好。长轮询频繁建立短连接，在HTTPS场景下每次连接都需进行TLS握手（虽然TLS 1.3已大幅优化，但仍有开销），在高延迟移动网络下性能差距更为明显。但长轮询的优势在于兼容性极佳，可穿透所有HTTP代理和防火墙，适合对网络环境兼容性要求极高的场景。

十六、SSE与短轮询（Short Polling）相比有什么优势？

1. 消息延迟差异

短轮询通过客户端周期性地发起HTTP请求检查是否有新数据，延迟取决于轮询间隔：间隔设为1秒则平均延迟500毫秒，间隔设为5秒则平均延迟2.5秒。SSE在服务器产生新数据的瞬间即可推送到客户端，延迟通常为毫秒级，在股票行情、实时通知等对时效性敏感的场景中具有压倒性优势。

2. 服务器负载差异

短轮询无论是否有新数据，客户端都会按固定频率发起请求，服务器需要为每个请求执行完整的处理流程（路由、认证、数据查询等）。在高并发场景下，大量"无新数据"的轮询请求会消耗大量服务器资源。SSE在无新数据时服务器无任何推送动作，仅维持连接空闲，仅在有新数据时才写入响应，服务器资源利用率显著更高。

3. 移动端电量与流量消耗差异

短轮询频繁发起HTTP请求，每次请求都需进行TCP连接建立和（若为HTTPS）TLS握手，会显著增加移动设备的无线电使用时间和电量消耗。SSE 通过单一长连接传输所有推送数据，避免了频繁建立连接的开销，在移动设备上的能效表现明显更优，有助于延长电池续航时间。

4. 适用场景差异

短轮询的实现最简单，无需服务器特殊支持，适用于数据更新频率极低（如每小时更新一次）或客户端数量极少的内网管理场景。SSE 适用于需要"近实时"数据更新的场景，且服务器需支持HTTP长连接。在实际选型时，若轮询间隔可设置为较长（如30秒以上）且数据实时性要求不高，短轮询因其极简的架构仍有一定应用价值。