在 Web 开发中，大多数人每天都在编写 HTTP 接口，却很少真正思考一个问题：如果服务端需要“主动”把消息推送给客户端，该怎么办？
传统的 HTTP 请求–响应模型决定了通信只能由客户端发起，这在即时通信、实时推送、在线协作等场景下显得力不从心。正是在这样的背景下，WebSocket 应运而生。
本文将从通信模型的角度出发，系统讲解 WebSocket 是如何工作的，以及它为何成为实时 Web 系统的核心技术。
一、为什么需要 WebSocket
1.HTTP 的先天缺陷
HTTP 是请求-响应模型：
客户端请求 → 服务端响应 → 连接关闭（或复用）
问题：
服务端不能主动推送数据
实时性差
高频轮询浪费资源
例如以下的场景：
聊天消息
股票行情
设备状态变化
如果用 HTTP进行轮询
客户端：有新消息吗？
客户端：有新消息吗？
客户端：有新消息吗？
客户端会一直发送请求，而服务端会一直判断请求的结果。这样会导致一系列问题比如：
低效、延迟高、服务器压力大
2.WebSocket 的核心目标
建立一次连接，长期保持，双向实时通信
WebSocket 让通信模型变成：
客户端 ⇄ 服务端（随时互相发消息）
二、WebSocket 的本质
WebSocket 的本质是借用 HTTP 握手兼容网络、基于 TCP 实现的全双工应用层长连接协议，核心解决了 Web 场景下 “服务端主动推数据” 的需求。
WebSocket 是 HTML5 规范定义的应用层协议（RFC 6455 标准），其底层完全依赖 TCP 协议提供的可靠字节流传输，最终实现「客户端与服务端的全双工、长连接通信」
WebSocket = 基于 TCP 的全双工长连接协议
三、WebSocket 握手全过程
WebSocket 通过HTTP Upgrade建立连接
WebSocket 为了兼容现有网络（防火墙、代理通常放行 HTTP），采用「HTTP 升级握手」的方式建立连接：
- 客户端发送 HTTP 请求，头部携带
Upgrade: websocket和Connection: Upgrade，声明要升级为 WebSocket 协议； - 服务端同意升级，返回 101 Switching Protocols 响应；
- 握手完成后，底层 TCP 连接被 “接管”，后续通信不再遵循 HTTP 规则，而是用 WebSocket 帧格式传输数据。
客户端发起 HTTP 请求
GET /ws HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
服务端返回 101 Switching Protocols
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
HTTP 协议结束，TCP 连接不关闭，开始使用WebSocket 帧协议
四、WebSocket 帧结构
| FIN | OPCODE | MASK | PAYLOAD LEN | DATA |
1. FIN：帧是否为消息的 “最后一帧”
核心作用：WebSocket 支持 “消息分片”—— 一个完整的消息可以拆分成多个帧发送，FIN标记当前帧是否是该消息的最后一帧；
若一条消息拆成3 帧发送：第 1、2 帧FIN=0，第 3 帧FIN=1；
2. OPCODE：帧的 “类型”（操作码）
| OPCODE 值 | 含义 | 场景 |
|---|---|---|
| 0x0（0） | 延续帧（Continuation Frame） | 消息分片时，非首帧的后续帧 |
| 0x1（1） | 文本帧（Text Frame） | 传输 UTF-8 文本数据（如 JSON） |
| 0x2（2） | 二进制帧（Binary Frame） | 传输二进制数据（如文件、图片） |
| 0x8（8） | 关闭帧（Close Frame） | 主动关闭连接时发送 |
| 0x9（9） | 心跳请求（Ping Frame） | 检测连接是否存活（服务端 / 客户端均可发） |
| 0xA（10） | 心跳响应（Pong Frame） | 收到 Ping 后必须回复 Pong |
3. MASK：载荷数据是否 “加掩码”
核心规则（强制）：
客户端 → 服务端：MASK=1（必须加掩码，否则服务端拒收）；
服务端 → 客户端：MASK=0（禁止加掩码）；
为什么加掩码？：防止恶意数据被中间件（如代理）误解为 HTTP 协议，提升安全性；
4. PAYLOAD LEN：载荷数据的长度
5. DATA：实际传输的 “有效数据”（PAYLOAD DATA）
五、Go 中 WebSocket 的基本使用
Go 标准库不直接提供 WebSocket，通常使用：github.com/gorilla/websocket
WebSocket 服务端
var upgrader = websocket.Upgrader{ CheckOrigin: func(r *http.Request) bool { return true // 生产环境需校验 }, } func wsHandler(w http.ResponseWriter, r *http.Request) { conn, err := upgrader.Upgrade(w, r, nil) if err != nil { return } defer conn.Close() for { msgType, msg, err := conn.ReadMessage() if err != nil { break } conn.WriteMessage(msgType, msg) } }核心步骤：
HTTP 请求进入 Handler
Upgrade()完成协议升级得到一个TCP Socket 长连接
WebSocket 客户端
conn, _, err := websocket.DefaultDialer.Dial( "ws://localhost:8080/ws", nil, ) if err != nil { panic(err) } defer conn.Close() conn.WriteMessage(websocket.TextMessage, []byte("hello")) _, msg, _ := conn.ReadMessage() fmt.Println(string(msg))六、WebSocket 的通信模型
一个连接 = 一个 Socket
一个连接
├── 读协程（Read Loop）
└── 写协程（Write Loop）
避免写阻塞读
避免并发写 panic
七、WebSocket 心跳机制
为什么需要心跳？
NAT / 代理会悄悄断连接
TCP 断了你不一定立刻知道
常见方式
ping / pong定时消息
// 设置 Pong 帧的处理函数：当收到对方（服务端/客户端）的 Pong 帧时，执行该回调 conn.SetPongHandler(func(string) error { // 重置连接的「读超时时间」为当前时间 + 60秒 conn.SetReadDeadline(time.Now().Add(60 * time.Second)) return nil // 无错误返回，标识 Pong 帧处理成功 })八、完整通信模型总结图（文字版）
HTTP 建立连接 ↓ Upgrade → WebSocket ↓ TCP 长连接保持 ↓ 消息驱动 + 全双工通信 ↓ 心跳维持连接 ↓ 任意一方关闭连接
WebSocket 基于 TCP 建立长连接，通信模型是全双工、消息驱动的，连接一旦建立，客户端和服务端都可以随时主动发送消息，适合实时、高频、双向通信场景。
