WebSocket 是一种在单个 TCP 连接上进行全双工通信的协议。它使得客户端和服务器之间Ke以进行实时、双向的数据传输。与传统的 HTTP 请求-响应模式不同，WebSocket 允许服务器主动向客户端推送数据，从而大大降低了延迟和网络开销。

hen多人误以为 WebSocket 是 HTTP 的一个版本或者升级，其实不然。WebSocket 和 HTTP 基本上是两个平行的世界。它们唯一的交集，就是为了兼容现有的 HTTP 网络环境，WebSocket 在建立连接的初期，借用了 HTTP 的服务器端口和握手流程。

一旦握手完成，WebSocket 就会“背叛” HTTP，摇身一变，切换成自己的 WebSocket 协议。这时候，HTTP 就再也管不着它了数据传输也不再遵循 HTTP 的格式。

WebSocket 连接的建立始于一个 HTTP 请求，该请求包含特定的头部字段，表明客户端希望将协议升级到 WebSocket。这个过程被称为“握手”。

其实一开始还是要用 HTTP 来“握手”。

客户端对服务器说：“嘿，我想升级成 WebSocket 聊天这是我的密钥，你kan行不行？”

服务器收到后拿着这个密钥和一把固定的“魔法钥匙”一组合，算出一个值，然后回复：“OK，切换协议，这是我的凭证，以后咱就用新规则聊天吧。”

之后这个 TCP 连接就变成了一条专用通道，两边随时Ke以互发消息。

当浏览器想要发起 WebSocket 连接时它会发送一个标准的 HTTP GET 请求，但在这个请求里夹带了一些“私货”：

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

这里有几个关键字段，咱们得好好琢磨一下：

Upgrade: websocket这是Zui核心的字段。它告诉服务器：“兄弟，我想换个协议玩，别用 HTTP 了咱们改用 WebSocket。”

Connection: Upgrade配合上面的 Upgrade 头使用，确认这是一个升级请求。

Sec-WebSocket-Key这是一个 Base64 编码的随机字符串。浏览器生成它，主要是为了防止缓存欺骗或者代理服务器的误判。这就像是一个“暗号”。

Sec-WebSocket-Version协议版本号，通常是 13。

服务器收到这个请求后Ru果它支持 WebSocket，并且同意建立连接，它就会返回一个 HTTP 101 状态码。响应头如下：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

注意这个 Sec-WebSocket-Accept 字段。它的生成过程有点意思：

服务器把客户端发来的 Sec-WebSocket-Key 拿出来。

拼上一个固定的 GUID 字符串：258EAFA5-E914-47DA-95CA-C5AB0DC85B11。

对拼接后的字符串进行 SHA-1 哈希运算。

再把哈希结果进行 Base64 编码。

算出来的这个值，就是 Sec-WebSocket-Accept。客户端收到后也会用同样的方法算一遍，Ru果对得上，说明握手成功，对方是正宗的 WebSocket 服务器；Ru果对不上，那就直接断开连接。

这一套流程走完，TCP 连接不断开，而是直接从 HTTP 协议切换到了 WebSocket 协议。从此以后这就是一条专属的高速公路了。

握手成功后咱们就Ke以愉快地发消息了。但是WebSocket 传输的数据可不像 HTTP 那样直接就是文本或者 JSON。WebSocket 定义了一套自己的数据格式，叫Zuo“帧”。

WebSocket 协议在设计上兼容 HTTP，它使用 HTTP 的 80 和 443 端口，并通过 HTTP 升级机制来建立连接。这种设计使得 WebSocket Ke以轻松地穿越防火墙和代理服务器。但是一旦连接建立，数据传输就完全不同了。

下图是参考 RFC6455 5.2 章节画的 WebSocket 基础帧的数据结构图，接下里我们重点解析下数据结构图：

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|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|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
| Masking-key        |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+

kan着这堆二进制位是不是有点晕？别急，咱们把它拆开来kan，其实就那么几个关键部分：

1 个比特。Ru果它是 1，说明这是消息的Zui后一个分片。Ru果是 0，说明后面还有数据，这是被拆分成了好几段传输的。通常咱们发的小消息，FIN dou是 1。

4 个比特。这个字段告诉接收端，这一帧到底是什么类型的数据。常见的有：

0x1 Zui常用，传输 UTF-8 编码的文本。

0x2 传输图片、音频、视频等二进制流。

0x8 一方发送这个，就表示要关闭连接了。

0x9 / 0xA 心跳帧，后面细说。

1 个比特。这是 WebSocket 协议里为了安全而设计的一个坑。

协议规定：客户端发给服务器的数据，MASK 必须是 1；服务器发给客户端的数据，MASK 必须是 0。

Ru果 MASK 是 1，说明后面的数据经过了掩码处理，需要用 Masking-key 解密。为什么要这么麻烦？主要是为了防止早期版本的代理服务器缓存中毒攻击。Ru果不加掩码，恶意用户可Neng通过 WebSocket 发送一些kan起来像 HTTP 请求的数据，把代理服务器搞晕。

7 个比特，或者 7 + 16，或者 7 + 64。这是一个变长的字段设计，非常精妙。

Ru果数据长度小于 125 字节，直接用这 7 个比特存长度。

Ru果是 126，说明后面紧跟着的 2 个字节才是真实长度。

Ru果是 127，说明后面紧跟着的 8 个字节才是真实长度。

这种设计既照顾了小数据包的头部开销，又支持了超大文件的传输。

Ru果 MASK 是 1，后面就会跟 4 个字节的 Masking-key。真正的数据就藏在 Payload Data 里它和 Masking-key Zuo过异或运算。接收端拿到数据后必须用同样的 Key 再异或一次才Neng还原出原始数据。

网络环境是复杂的。有时候，虽然 TCP 连接没有断开，但中间的路由器、防火墙或者 NAT 网关可Neng会因为长时间没有数据流动而悄悄切断连接。这时候，客户端和服务器dou以为连着呢，结果发消息发不出去。

为了解决这个问题，WebSocket 引入了心跳机制。

WebSocket 提供了 Ping 和 Pong 帧来实现连接保活。一方Ke以发送 Ping 帧，另一方必须回应 Pong 帧。这有助于检测连接是否意外中断，并维持中间网络设备的会话状态。

Ping/Pong 帧的 opcode 分别为 0x9 和 0xA，负载数据可选。

这就像两个人打 六、 安全性：WSS 的保驾护航

既然 WebSocket 是明文传输的，那中间人攻击、数据窃听这些风险就不可避免。特别是在金融、支付等敏感领域，裸奔的 WebSocket 是绝对不Neng接受的。

于是就有了 WSS。

WebSocket 支持安全传输，即 WebSocket over TLS，通常称为 WSS。与 HTTPS 类似，WSS 使用 wss:// 协议标识，连接建立在 TLS 之上，确保数据的机密性和完整性。WSS 的握手也是通过 HTTP over TLS 进行的，然后切换到加密的 WebSocket 通信。

使用 WSS Ke以有效防止中间人攻击和数据窃听，尤其对于生产环境至关重要。现在的浏览器对混合内容限制越来越严，所以建议大家在实际开发中，尽量直接上 WSS。

WebSocket 协议通过一次 HTTP 升级握手，建立起一个持久、全双工的 TCP 连接，极大地简化了实时 Web 应用的开发。其轻量级的帧格式、内置的心跳机制以及基于 TLS 的安全 ，使得它成为现代 Web 实时通信的标准方案。

从早期的 Ajax 轮询，到长轮询，再到如今的 WebSocket，Web 交互的体验正在变得越来越像原生应用。无论是多人在线协作文档、即时通讯软件，还是实时的股票大盘，背后dou有 WebSocket 在默默支撑。

理解 WebSocket 的工作原理，有助于我们geng好地设计高实时性、低延迟的网络应用。希望这篇文章Neng帮你彻底搞懂 WebSocket 的那些事儿。下次再有人问你 WebSocket 原理，别只说“它是全双工的”，把那个“打

参考资料：RFC 6455 - The WebSocket Protocol