客户端会发一个特殊的HTTP请求，带上Upgrade: websocket的头，意思是：“大哥，咱们Neng不Neng换个协议聊？”

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket              ← 请求升级协议
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZQ==   ← 随机 key
Sec-WebSocket-Version: 13

Ru果服务器支持，就会返回一个101 Switching Protocols的状态码：

HTTP/1.1 101 Switching Protocols    ← 表示协议切换
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=  ← 验证 key

这一步完成后这条TCP连接上传输的就不再是HTTP文本了而是WebSocket的二进制帧格式。

WebSocket的数据传输格式非常严谨，它定义了帧的概念：

  +-+-+-+-+-------+-+-------------+-------------------------------+
  |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
  |I|S|S|S|    |A|          |                        |
  |N|V|V|V|       |S|             |      |
  | |1|2|3|       |K|             |                               |
  +-+-+-+-+-------+-+-------------+-------------------------------+
  |     Masking-key    |                               |
  +-------------------------------+-------------------------------+
  |                     Payload Data                              |
  +---------------------------------------------------------------+

这Yi经和HTTP完全无关了是独立的二进制协议。这意味着它传输效率geng高，支持geng复杂的数据类型。

建立连接后客户端和服务端地位平等了。谁想说话就说话，不需要再等对方问。

客户端                              服务端
  │                                  │
  │── GET /chat │  ← HTTP 握手请求
  │<── 101 Switching Protocols ─────│  ← 协议升级成功
  │                                  │
  │ ═══════ WebSocket 连接建立 ═══════│  ← 不再是 HTTP 了
  │                                  │
  │──── {"msg": "你好"} ──────────>│  ← 客户端发
  │<─── {"msg": "你好！有什么Ke以帮你？"}│  ← 服务端发
  │──── {"msg": "帮我写代码"} ─────>│  ← 客户端发
  │<─── {"msg": "好的，请稍等"} ────│  ← 服务端发
  │<─── {"msg": "代码写好了"} ──────│  ← 服务端主动发
  │                                  │
  │ ═══════ 任意一方关闭 ═════════════│

这种模式特别适合聊天室、在线游戏、协同编辑这种双方互动频率极高的场景。

咱们把视角拉高，kankan这三者在传输层TCP眼里是个啥样。其实它们底层用的dou是同一条TCP连接，区别只在于上面跑的是什么格式的数据、谁Neng发、什么时候关。

TCP 连接建立 → 发请求 → 收响应 → TCP 连接关闭

一条TCP连接只活了0.4秒。用完即弃，简单粗暴。

TCP 连接建立 → 发请求 → 收响应头 → 收数据块 → 收数据块 → ... → TCP 连接关闭

一条TCP连接活了46秒。期间服务端不断往里写数据，客户端一直读。

TCP 连接建立 → HTTP 握手 → 协议升级 → 双向帧传输 → ... → TCP 连接关闭

一条TCP连接可Neng活几个小时。双方随时互发数据，这才是真正的“长连接”。

光说不练假把式，咱们来kankan代码里怎么用。这里以Spring Boot为例。

后端利用WebFlux的Flux流式特性，非常优雅：

@GetMapping
public Flux stream {
    return Flux.create(sink -> {
        // 模拟 AI 逐字输出
        tokenStream
            .onPartialResponse(token -> {
                sink.next;  // → 变成 data:xxx

 写入 TCP
            })
            .onComplete -> {
                sink.complete;   // → 写入 event:done，关闭连接
            });
    });
}

前端直接用浏览器自带的EventSource

// 前端
const es = new EventSource
es.onmessage =  => {
    const data = JSON.parse
    // 每收到一条就处理，不需要等全部完成
    appendToPage
}
es.addEventListener => {
    es.close  // 手动关闭
})

WebSocket稍微复杂一点，需要配置Handler：

@Configuration
@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {
    @Override
    public void registerWebSocketHandlers {
        registry.addHandler, "/ws/chat");
    }
    @Bean
    public WebSocketHandler chatHandler {
        return new TextWebSocketHandler {
            @Override
            protected void handleTextMessage {
                // 收到客户端消息
                String payload = message.getPayload;
                // 服务端Ke以随时主动发
                session.sendMessage);
            }
        };
    }
}

前端使用WebSocket API：

// 前端
const ws = new WebSocket
ws.onopen =  => {
    ws.send  // 客户端 → 服务端
}
ws.onmessage =  => {
    console.log  // 服务端 → 客户端
}
ws.send  // 随时Ke以发

讲了这么多，Zui后还是得回到实际应用场景。别kan技术花里胡哨，选对工具才是关键。

我整理了一个简单的决策表，大家Ke以直接抄作业：

HTTP 是“你问我答”，SSE 是“你问一次我一直答”，WebSocket 是“咱俩随便聊”。

三者底层dou是TCP连接，区别只在于谁Neng说话、说多久、什么时候挂。

事件频率低 → 轮询就够了简单可靠，别整复杂的。

事件频率高 → 必须 SSE，轮询Zuo不了WebSocket又太重。

需要双向通信 → WebSocket，这是它的主场，别用SSE硬凑。

技术选型从来不是kan哪个技术Zui新、Zui酷，而是kan哪个Zui适合当下的业务场景。HTTP虽然老，但依然是互联网的基石；SSE虽然小众，但在AI时代迎来了第二春；WebSocket虽然强大，但维护成本也不低。

希望这篇文章Neng帮你彻底理清这三者的关系。下次再遇到“实时推送”的需求，别再傻傻地写setInterval轮询了也别上来就上WebSocket，先想想：我是不是只需要SSE就够了？