在前端面试的深水区，WebSocket 始终是一个绕不开的高频考点。是面对像字节跳动、腾讯这样对计算机网络基础有严苛要求的面试官时仅仅回答“它能实现实时通信”或者“比轮询性能好”是远远不够的。

面试官真正想听到的，是你对于协议升级机制全双工通信模型还有工程化落地难点的深度理解。

今天我们将结合一个基于 Koa + koa-websocket 的实战案例。从底层协议握手、代码实现细节，到心跳保活机制，全方位拆解 WebSocket。其实，

一、面试官心理战：为什么是 WebSocket？怎么说呢，

使用者痛点：很多候选人在回答“WebSocket 与 SSE 的区别”时只停留在表层概念。无法说明 HTTP 的根本局限还有真实业务场景下的性能瓶颈。

在开始写代码之前，我们必须先解决“为什么”的问题。这通常是面试的开场白，也是考察你对技术选型思考深度的第一关。

至于面试官常问，“WebSocket 和 SSE 有什么区别？为什么聊天室要用 WebSocket？”需要从HTTP 的局限性切入，建立一个完美的回答逻辑：

• HTTP 轮询的痛点传统的 HTTP 协议是基于“请求-响应”模式的。要实现实时聊天客户端必须不断轮询，而且极度浪费带宽——每次 HTTP 请求都携带冗长的 Header。而有效载荷可能只有几个字节的聊天内容。
• SSE 的单向性SSE 基于 HTTP 长连接，但本质上是单向。它非常适合 LLM 流式输出、股票行情推送等场景，却无法处理使用者主动发送消息的需求。
• WebSocket 的全双工优势HTML5 提供的全双工通信协议。它基于 TCP，一旦握手成功。客户端和服务端就可以互相主动推送数据，且头部开销极小。不过，

二、主要原理：Switching Protocols 握手详解

使用者痛点： 候选人常把握手过程简化为“建立连接”。导致面试官追问细节时卡壳。

This is hardest part in an interview. 面试官希望听到你对握手过程的精准描述，而不是模糊的“建立连接”。当我们在前端执行 new WebSocket 时浏览器利用 HTTP “欺骗”服务器完成一次协议升级。

标准答案要点：

• The client sends a special HTTP GET request containing upgrade headers.
• The server replies with 101 Switching Protocols if it supports WebSocket.
• The connection n switches from HTTP to a binary frame based TCP stream.

• Upgrade: websocket — 明确告知服务器希望升级到 wss/websocket.
• Connection: Upgrade — 表明这是一次协议升级请求，而非普通 HTTP 请求。
• Sec-WebSocket-Key — 客户端生成的随机 Base64 编码字符串，防止缓存代理误处理。
• Sec-WebSocket-Version — 通常为 "13",表示支持的协议版本。说起来，

• Status code "101 Switching Protocols".
• The server concatenates received S​ec‑WebSocket‑Key with GUID "258EAFA5‑E914‑47DA‑95CA‑C5AB0DC85B11"。hashes it with SHA‑1,n Base64 encodes result as S​ec‑WebSocket‑Accept.
• If client validates this value,upgrade succeeds and both sides start exchanging frames.