SSE vs WebSocket：从消息推送原理到选型指南（附Java对比实现）

SSE与WebSocket深度对比：Java实战与架构选型指南

1. 实时通信技术演进与核心需求

在数字化转型浪潮中，实时通信已成为现代应用的基础能力。从金融交易系统到在线协作平台，从物联网设备监控到即时消息推送，对数据实时性的要求正推动着技术架构的持续革新。当我们讨论实时通信方案时，SSE（Server-Sent Events）和WebSocket是两种最常被提及的技术选择。

实时通信的本质矛盾在于：传统的HTTP请求-响应模式无法满足服务器主动推送的需求。早期解决方案如轮询（Polling）和长轮询（Long Polling）都存在明显缺陷——前者产生大量无效请求，后者虽然减少请求次数但仍保持高连接开销。SSE和WebSocket正是在这样的背景下诞生的新一代解决方案。

理解这两种技术的差异需要从协议层入手。SSE本质上仍是HTTP协议，它利用HTTP/1.1的长连接特性，通过text/event-stream内容类型保持连接开放。而WebSocket则是独立的应用层协议，在完成HTTP握手后升级为全双工通信通道。这种根本差异导致了它们在功能特性和适用场景上的显著区别。

2. 协议层深度解析

2.1 SSE技术架构

SSE的工作机制可以概括为以下几个关键点：

1. 连接建立：客户端发起常规HTTP GET请求，携带Accept: text/event-stream头部
2. 响应格式：服务器返回Content-Type: text/event-stream，并保持连接开放
3. 消息格式：事件流由多个消息组成，每个消息以两个换行符分隔，格式如下：

event: notification
id: 12345
retry: 5000
data: {"time":"2024-03-20","content":"系统更新通知"}

SSE的Java实现核心是Spring的SseEmitter类。以下是一个典型的生产级实现：

@RestController
@RequestMapping("/api/sse")
public class SseController {
    private final Map<String, SseEmitter> emitters = new ConcurrentHashMap<>();
    
    @GetMapping("/subscribe/{userId}")
    public SseEmitter subscribe(@PathVariable String userId) {
        SseEmitter emitter = new SseEmitter(30_000L); // 30秒超时
        emitters.put(userId, emitter);
        
        emitter.onCompletion(() -> emitters.remove(userId));
        emitter.onTimeout(() -> emitters.remove(userId));
        emitter.onError(e -> {
            log.error("SSE error for user {}", userId, e);
            emitters.remove(userId);
        });
        
        return emitter;
    }
    
    @PostMapping("/notify/{userId}")
    public ResponseEntity<?> notifyUser(
        @PathVariable String userId,
        @RequestBody NotificationDto notification) {
        
        SseEmitter emitter = emitters.get(userId);
        if (emitter != null) {
            try {
                emitter.send(SseEmitter.event()
                    .id(UUID.randomUUID().toString())
                    .name("notification")
                    .data(n