WebSocket 是一种基于 TCP 的全双工通信协议，专为解决 HTTP 协议在实时通信场景中的局限性而设计。其核心是 建立持久连接后实现客户端与服务器的双向实时通信，工作原理可分为 握手阶段和 数据传输阶段两大过程。

一、WebSocket 的核心目标

HTTP 采用“请求-响应”模式，服务器无法主动向客户端发送数据，若需实时性（如聊天），只能通过客户端轮询（Polling）或长轮询（Long Polling）实现，效率低下且资源消耗大。

WebSocket 的设计目标是：

1. 建立持久连接，避免频繁创建/关闭连接的开销；
2. 支持双向通信，客户端和服务器可随时主动发送数据；
3. 减少冗余数据传输（相比 HTTP 头部，WebSocket 数据帧更轻量）。

二、WebSocket 的工作原理详解

1. 握手阶段：基于 HTTP 协议升级连接

WebSocket 并非完全独立于 HTTP，而是通过 HTTP 协议的“升级机制”完成连接建立（握手），这是为了兼容现有网络基础设施（如代理、防火墙）。

握手流程：

• 步骤 1：客户端发送升级请求
  客户端（如浏览器）向服务器发送一个特殊的 HTTP 请求，表明“希望将连接升级为 WebSocket 协议”。
  核心请求头包括：

  • Upgrade: websocket：声明要升级的协议类型；
  • Connection: Upgrade：确认升级意图；
  • Sec-WebSocket-Key：客户端生成的随机字符串（Base64 编码），用于服务器验证；
  • Sec-WebSocket-Version: 13：指定协议版本（现代浏览器均支持 13 版本）。

  请求示例：

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

• 步骤 2：服务器验证并响应
  服务器收到请求后，若同意升级，则返回 HTTP 101 状态码（Switching Protocols），并通过 Sec-WebSocket-Accept 头验证合法性。

  验证逻辑：

  1. 将客户端发送的 Sec-WebSocket-Key 与固定 UUID 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 拼接；
  2. 对拼接后的字符串进行 SHA-1 哈希计算；
  3. 将哈希结果转换为 Base64 编码，作为 Sec-WebSocket-Accept 的值返回。

  响应示例：

  HTTP/1.1 101 Switching Protocols
  Upgrade: websocket
  Connection: Upgrade
  Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
  

• 步骤 3：握手成功，协议切换
  客户端验证 Sec-WebSocket-Accept 的值（与本地计算结果对比），若一致则握手成功。此时，底层的 TCP 连接被复用，但通信协议从 HTTP 切换为 WebSocket，后续数据传输不再使用 HTTP 格式。

2. 数据传输阶段：基于帧（Frame）的二进制协议

握手成功后，客户端与服务器通过WebSocket 帧进行通信。帧是 WebSocket 数据传输的基本单位，采用二进制格式，结构紧凑（头部最小仅 2 字节），大幅降低通信开销。

帧结构解析（简化版）：

  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|  (4)  |A|     (7)     |             (16/64)           |
 |N|V|V|V|       |S|             |                               |
 +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
 |     Extended payload length continued, if payload len == 126  |
 + - - - - - - - - - - - - - - - +-------------------------------+
 |     Extended payload length continued, if payload len == 127  |
 +-------------------------------+-------------------------------+
 |                               |Masking-key, if MASK set to 1  |
 +-------------------------------+-------------------------------+
 | Masking-key (continued)       |          Payload Data         |
 +-------------------------------- - - - - - - - - - - - - - - - +
 :                     Payload Data continued ...                :
 + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
 |                     Payload Data continued ...                |
 +---------------------------------------------------------------+

核心字段说明：

• FIN（1 位）：是否为消息的最后一帧（1 = 最后一帧，0 = 消息分片传输）；
• opcode（4 位）：数据类型，如：
  • 0x1：文本数据（UTF-8 编码）；
  • 0x2：二进制数据；
  • 0x8：关闭连接帧；
  • 0x9/0xA：心跳检测（Ping/Pong）。
• MASK（1 位）：是否对数据加密（客户端发送的帧必须置为 1，服务器发送的帧必须置为 0）；
• Payload length（7/16/64 位）：数据长度（0-125 直接表示，126 表示后续 2 字节为长度，127 表示后续 8 字节为长度）；
• Masking-key（32 位）：客户端发送数据时的加密密钥（用于解密 Payload Data）；
• Payload Data：实际传输的数据（文本或二进制）。

数据传输特点：

• 全双工：客户端和服务器可同时发送数据，无需等待对方响应；
• 消息分片：大消息可拆分为多个帧传输（通过 FIN 位标识是否结束）；
• 轻量头部：相比 HTTP 每次请求的头部（可能数百字节），WebSocket 帧头部最小仅 2 字节，适合高频通信；
• 加密支持：可通过 wss:// 协议（基于 TLS/SSL）加密传输，确保安全性。

3. 连接维护与关闭

• 心跳检测：为防止连接因超时被中间代理关闭，客户端/服务器可发送 Ping 帧（opcode 0x9），对方需回复 Pong 帧（opcode 0xA），维持连接活性。
• 关闭连接：任何一方可发送 Close 帧（opcode 0x8），包含关闭状态码和原因，对方确认后关闭 TCP 连接，确保资源正确释放。

三、WebSocket 与 HTTP 的本质区别

维度	HTTP	WebSocket
连接类型	短连接（或通过 Keep-Alive 维持的半持久连接）	持久连接（一次握手，长期保持）
通信方向	单向（客户端请求 → 服务器响应）	双向（客户端 ↔ 服务器，全双工）
数据格式	文本（HTTP 头部 + 实体）	二进制帧（紧凑结构，无冗余头部）
适用场景	客户端主动获取数据（如网页浏览、API 调用）	实时双向通信（如聊天、游戏、监控）

总结

WebSocket 的工作原理可概括为：“HTTP 握手建立连接，TCP 复用传输帧数据”。通过一次 HTTP 升级握手，将短连接转换为持久连接，再通过轻量的二进制帧格式实现双向实时通信，完美解决了 HTTP 在实时场景中的效率问题。

如今，WebSocket 已成为实时应用的标准选择，被广泛用于聊天工具、在线协作、金融行情、游戏等场景，其设计思想也影响了 HTTP/2 的服务器推送（Server Push）功能。