你打开 Wireshark 抓个包，或者浏览器的 Network 面板瞅一眼，会发现客户端发的第一个请求长这样：

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

kan到那个 Upgrade: websocket 了吗？这就是客户端在跟服务器喊话：“大哥，别用 HTTP 聊了咱们升级协议吧，我想用 WebSocket！”

还有那个 Sec-WebSocket-Key，这玩意儿是个随机生成的 Base64 字符串。服务端收到后必须Zuo一套极其严格的规范动作：把这串 Key 跟一个固定的 GUID 拼起来算一下 SHA-1 哈希值，再转成 Base64，通过 Sec-WebSocket-Accept 返回给客户端。

⚠️ 为什么要这么折腾？防黑客吗？

错！这根本不是为了防黑客。这是为了防止无意的“缓存投毒”，并且让客户端确认：“对面这台服务器是真的懂 WebSocket 协议，而不是碰巧返回了 200 OK”。这就像是对暗号，对上了才Neng进屋喝茶。

连接建立后HTTP 的使命就结束了接下来的通信就变成了 WebSocket 协议。这时候传输的数据不叫报文，叫“数据帧”。

协议底层定义了一个 bit 的 Opcode，用来告诉对方这一帧是文本消息、二进制数据，还是心跳包。这才是它Neng扛起复杂互动场景的全Neng底气。

Talk is cheap，咱们直接上代码。用 Koa 撸一个 WebSocket 服务器其实非常优雅：

const Koa = require;
const websocket = require;
// 注入 WebSocket Neng力
const app = websocket);
const clients = new Set; // 维护客户端连接池
// 处理 WebSocket 长连接逻辑
app.ws.use => {
    clients.add; // 用户上线
    // 服务端接收到消息时广播给所有人
    ctx.websocket.on('message', message => {
        for  {
            client.send);
        }
    })
    // 划重点：断开连接时必须清理内存，否则会导致内存泄漏！
    ctx.websocket.on => {
        clients.delete;
    })
})
app.listen;

代码逻辑hen简单，但面试官真正在意的是下面这两个底层护城河内存管理和连接保活。

不管你用 WS 还是 SSE，只要写了“长连接”，面试官必放终极杀招：

“Ru果用户进了电梯没信号了或者直接拔了网线，你的服务器怎么知道他掉线了？”

千万别回答“等 TCP 超时断开”——TCP 底层的 Keep-Alive 默认要两小时才触发，那时候你服务器的连接池早被死链接撑爆了！

正确的Zuo法是在应用层实现心跳机制。就像打 四、 杀鸡焉用牛刀：SSE 的崛起

既然 WebSocket 这么强，全双工、低延迟，那为什么我们用 ChatGPT 或 DeepSeek 时抓包发现它们根本没用 WebSocket，而是用了 SSE ？

因为业务场景变了！

大模型的“打字机效果”，是一个单向流式输出的过程。你发一句 Prompt，AI 连续吐出几百个词。这个场景根本不需要全双工双向发消息，只需要服务器单向高频推送即可！

这时候用 WebSocket，就像是为了送一封信，专门修了一条双向八车道的高速公路，太浪费了。处理单向推送，SSE 才是Zui优雅的神！

hen多小白把 SSE 当成什么高深的新协议，大错特错！SSE 是 100% 纯正的 HTTP/1.1 协议。它不需要握手升级，不需要新的端口，它就是利用了 HTTP 响应头里的几个字段，把一个普通的 HTTP 响应变成了“源源不断的数据流”。

它的核心黑科技，是利用了 HTTP 响应头里的 Transfer-Encoding: chunked

Content-Type: text/event-stream
Transfer-Encoding: chunked
Connection: keep-alive

正常的 HTTP 请求必须带 Content-Length，浏览器拿到指定大小的数据就关门大吉。但加上 chunked 后服务器的意思是：“我也不知道 AI 要说多少废话，我一块一块发给你吧，你别急，我没发完就不算结束。”

服务器每次吐出一个字，就按 data: 你好 的格式发过去。浏览器底层的流处理器只要读到 ，就知道一块数据到了立刻触发前端的渲染。这就是那个丝滑的“打字机效果”背后的原理。

面试官Zui后肯定会问：“那你说说什么时候用 WebSocket，什么时候用 SSE？”

这时候，千万别背书，要结合场景。

WebSocket： Zuo联机游戏、协同文档、实时聊天室，毫不犹豫选它。因为它需要双向，客户端不仅要收，还要发。而且 WebSocket 支持二进制数据，性Nenggeng强。

SSE： Zuo大模型对话、站内单向消息通知、股票行情推送，选轻量级、原生兼容 HTTP 的 SSE。因为它单向，且基于 HTTP，不需要像 WebSocket 那样处理握手协议，浏览器自动支持重连，开发成本极低。

为了方便大家记忆，我整理了一个简单的对比逻辑：

通信方向： SSE 是单向；WebSocket 是双向。

底层协议： SSE 跑在 HTTP 上；WebSocket 是独立的 TCP 协议。

数据格式： SSE 只Neng发文本；WebSocket 支持文本和二进制。

断线重连： SSE 浏览器原生支持自动重连；WebSocket 得自己写逻辑。

俗话说得好：“面试造火箭，工作拧螺丝”。但Ru果你连长连接的底层协议dou搞不清楚，可Neng连进大厂拧螺丝的资格dou没有。

Transfer-Encoding: chunked 不再是一个冷门的 HTTP 头，而是每一个前端工程师必须掌握的利器。希望这篇文章Neng帮你把 WebSocket 和 SSE 的原理彻底吃透。下次面试官再问，你就自信地把这些底层逻辑甩在他脸上，Offer 自然就到手了！