WebSocket 协议与原理

本篇是 WebSocket 实时通信系列教程的第一篇。我们将从「为什么需要 WebSocket」讲起，对比 HTTP 与 WebSocket 的本质差异，深入剖析 WebSocket 协议的握手过程、数据帧格式、心跳机制与生命周期，最后梳理 Go 生态中主流的 WebSocket 库。理解这些底层原理，是写出可靠、高性能实时应用的基础。

一、为什么需要 WebSocket

在 Web 开发中，「服务器主动推送消息给浏览器」这个需求长期存在：即时聊天、实时股价、在线协作、消息通知、多人游戏……这些场景都有一个共同特征——数据需要在服务器产生后尽快到达客户端，而不是等客户端主动来问。

传统的 HTTP 协议是为「请求-响应」模型设计的：客户端发请求，服务器返响应，连接就结束了。服务器无法在「没有请求」的情况下主动把数据推给客户端。这种半双工的模式在面对实时场景时显得力不从心，开发者不得不借助各种「曲线救国」的手段。

WebSocket 就是为了解决这个问题而诞生的。它在 2011 年被标准化为 RFC 6455，设计目标很明确：在 Web 上提供全双工、低开销、双向的通信通道。建立连接后，客户端和服务器都可以随时向对方发送数据，而不需要每次都重新建立连接、重复发送头部。

实时通信的本质是「让数据尽可能快地从生产者到达消费者」。WebSocket 通过保持长连接和双向通信，把延迟降到了最低。

二、HTTP vs WebSocket

理解 WebSocket 最好的方式，是把它和 HTTP 放在一起对比。

1. 请求-响应 vs 全双工

HTTP 是半双工协议：同一时刻只能有一个方向的数据传输。客户端发请求时，服务器不能插话；服务器返响应时，客户端也不能打断。一次 HTTP 交互就是一个完整的「问答」回合，回合结束连接就关闭（HTTP/1.1 默认 keep-alive 会复用 TCP 连接，但语义上仍是一问一答）。

WebSocket 是全双工协议：连接建立后，客户端和服务器可以同时、随时向对方发送数据，互不阻塞。这就像打电话，双方都可以说话，而不是对讲机那种「说完一句按一下按钮」。

package main

import (
	"fmt"
	"net/http"
	"time"
)

// 演示 HTTP 的请求-响应模式：服务器无法主动推送
func httpHandler(w http.ResponseWriter, r *http.Request) {
	// 服务器只能在收到请求后返回一次响应
	fmt.Fprintf(w, "当前时间: %s\n", time.Now().Format(time.RFC3339))
	// 响应返回后，这次交互就结束了，服务器无法再推送新数据
}

func main() {
	http.HandleFunc("/time", httpHandler)
	fmt.Println("HTTP 服务器监听 :8080")
	// 客户端想获取最新时间，必须不断轮询 /time 接口
	http.ListenAndServe(":8080", nil)
}

上面这个 HTTP 例子暴露了一个问题：如果客户端想「实时」知道时间变化，只能每隔一段时间发一次请求。这在实时性要求高的场景下既低效又笨拙。

2. 轮询、长轮询、SSE、WebSocket 对比

在 WebSocket 出现之前，开发者已经发明了多种「模拟实时」的方案。我们逐一分析它们的原理和优缺点。

短轮询（Polling）

客户端定时发 HTTP 请求询问服务器「有没有新消息」，服务器无论有没有都立即返回。实现最简单，但缺点明显：大部分请求是无效的，浪费带宽和服务器资源；实时性取决于轮询间隔，间隔越短越实时但越浪费。

长轮询（Long Polling）

客户端发请求后，服务器不立即返回，而是挂起请求直到有新消息（或超时）才响应。客户端收到响应后立即发起下一次请求。相比短轮询大幅减少了无效请求，实时性也更好。但每次消息仍然需要重新建立 HTTP 请求，头部开销依然存在。Facebook 早期的聊天就是用长轮询实现的。

SSE（Server-Sent Events）

基于 HTTP 的单向推送：服务器可以通过一个持久 HTTP 连接向客户端推送事件流。浏览器原生支持 EventSource API。SSE 是「服务器到客户端」的单向推送，客户端到服务器仍需用普通 HTTP。适合通知、行情这类只需要服务器推送的场景。

WebSocket

全双工、双向、低开销。建立连接后双方可随时发送数据，数据帧头部只有 2~14 字节，远小于 HTTP 头部。适合聊天、协作、游戏等需要频繁双向交互的场景。

方案	通信方向	连接类型	实时性	开销	适用场景
短轮询	双向（模拟）	短连接	低	高	简单、低频更新
长轮询	双向（模拟）	长连接	中	中	兼容性要求高的实时场景
SSE	服务器→客户端	长连接	中高	低	通知、行情、日志推送
WebSocket	全双工	长连接	高	低	聊天、协作、游戏、双向交互

3. 一个直观的对比示例

下面用一个 Go 程序对比展示轮询和长轮询的差异，帮助理解为什么需要更高效的方案：

package main

import (
	"fmt"
	"net/http"
	"time"
)

var lastMessage = "初始消息"
var messageTime = time.Now()

// 短轮询：立即返回当前状态
func shortPollingHandler(w http.ResponseWriter, r *http.Request) {
	fmt.Fprintf(w, "短轮询 -> %s (产生于 %s)", lastMessage, messageTime.Format("15:04:05"))
}

// 长轮询：如果没有新消息则等待，直到超时或有新消息
func longPollingHandler(w http.ResponseWriter, r *http.Request) {
	deadline := time.Now().Add(30 * time.Second)
	for time.Now().Before(deadline) {
		// 简化演示：假设每秒检查一次是否有新消息
		if time.Since(messageTime) < time.Second {
			fmt.Fprintf(w, "长轮询收到新消息 -> %s", lastMessage)
			return
		}
		time.Sleep(time.Second)
	}
	// 超时返回空响应，客户端会立即发起新的长轮询
	w.WriteHeader(http.StatusNoContent)
}

func main() {
	// 模拟后台每隔 10 秒产生一条新消息
	go func() {
		for i := 1; ; i++ {
			time.Sleep(10 * time.Second)
			lastMessage = fmt.Sprintf("第 %d 条消息", i)
			messageTime = time.Now()
		}
	}()

	http.HandleFunc("/short", shortPollingHandler)
	http.HandleFunc("/long", longPollingHandler)
	fmt.Println("对比服务器监听 :8080")
	http.ListenAndServe(":8080", nil)
}

可以看到，长轮询虽然比短轮询好，但每次消息都要重新走一遍 HTTP 请求-响应流程。WebSocket 则把这些开销全部省掉——连接建立一次，之后双方想发就发。

三、WebSocket 协议详解

WebSocket 协议（RFC 6455）定义了两个部分：握手（基于 HTTP）和数据传输（基于自定义帧格式）。理解这两部分是掌握 WebSocket 的关键。

1. 握手过程：HTTP Upgrade

WebSocket 的握手复用了 HTTP 协议。客户端发起一个特殊的 HTTP 请求，携带 Upgrade: websocket 头部，请求服务器把当前连接「升级」为 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

服务器握手响应示例：

http

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 编码得到的。这个机制是为了防止普通 HTTP 服务器误响应 WebSocket 请求。

下面用 Go 模拟这个握手过程，帮助理解：

package main

import (
	"crypto/sha1"
	"encoding/base64"
	"fmt"
)

// 模拟 WebSocket 握手中 Sec-WebSocket-Accept 的计算过程
func computeAcceptKey(clientKey string) string {
	const guid = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
	h := sha1.New()
	h.Write([]byte(clientKey + guid))
	return base64.StdEncoding.EncodeToString(h.Sum(nil))
}

func main() {
	// 客户端发送的 Sec-WebSocket-Key
	clientKey := "dGhlIHNhbXBsZSBub25jZQ=="
	accept := computeAcceptKey(clientKey)
	fmt.Println("客户端 Key:", clientKey)
	fmt.Println("服务端 Accept:", accept)
	// RFC 6455 示例中规定，对这个 key 计算得到的 accept 应为：
	// s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
}

运行这段代码，你会得到 s3pPLMBiTxaQ9kYGzzhZRbK+xOo=，这正好是 RFC 文档里给出的标准答案。理解了这个计算过程，你就明白握手阶段服务器在做什么校验了。

2. 数据帧格式：FIN、opcode、mask

握手完成后，双方按 WebSocket 的**帧（frame）**格式传输数据。一个帧的结构（RFC 6455 5.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|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
|     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 bit）：是否是消息的最后一个帧。WebSocket 允许把一条大消息拆成多个帧发送，最后一个帧 FIN=1。
RSV1/2/3（各 1 bit）：保留位，除非使用了扩展（如压缩），否则必须为 0。
opcode（4 bit）：帧类型，决定了 payload 如何解释。
MASK（1 bit）：payload 是否被掩码。客户端发往服务器的帧必须掩码，服务器发往客户端的帧不能掩码，这是协议规定。
Payload len（7 bit）：payload 长度。0~125 直接表示长度；126 表示后接 2 字节扩展长度；127 表示后接 8 字节扩展长度。
Masking-key（32 bit）：掩码密钥，仅当 MASK=1 时存在。
Payload Data：实际数据。

opcode 取值定义了帧的类型：

opcode	含义	说明
0x0	continuation	分片消息的后续帧
0x1	text frame	文本帧（UTF-8）
0x2	binary frame	二进制帧
0x8	close	关闭帧
0x9	ping	心跳请求
0xA	pong	心跳响应

3. 文本帧 vs 二进制帧

文本帧（opcode=0x1）的 payload 必须是合法的 UTF-8 文本。它通常用来传输 JSON、XML、纯文本等结构化数据。接收方可以安全地按字符串处理。

二进制帧（opcode=0x2）的 payload 是任意字节序列，没有编码约束。它适合传输图片、Protobuf、音视频流等二进制数据。

在实际开发中，文本帧更易调试（可以直接看到内容），二进制帧更高效（无需字符串编解码）。选择哪种取决于你的数据格式和性能要求。

一个常见误区：认为文本帧只能传字符串。实际上你可以把 JSON 序列化成字节后用二进制帧发送，也可以把字节当文本帧发。区别只在于 opcode 标记和「是否要求 UTF-8 校验」。

4. Ping/Pong 心跳

WebSocket 连接是长连接，但长连接会面临一个问题：如果中间网络设备（NAT、防火墙、负载均衡）长时间没看到流量，可能会把连接悄悄断开。为了保活，WebSocket 协议定义了 Ping/Pong 控制帧。

一方发送 Ping（0x9） 帧，对方必须尽快回一个 Pong（0xA） 帧，且 Pong 的 payload 要和 Ping 一致。
Ping/Pong 可以由任意一方发起，但通常由服务器发起（也可以由客户端发起）。
控制帧的 payload 最多 125 字节。

心跳有两个作用：保活（防止连接被中间设备断开）和探活（检测对方是否还活着）。如果发出去的 Ping 迟迟收不到 Pong，就可以认为连接已死，主动关闭。

5. Close 帧

关闭一个 WebSocket 连接应该发送 Close（0x8） 帧做「优雅关闭」。Close 帧可以携带一个 2 字节的状态码和一段关闭原因文本。

常见状态码：

状态码	含义
1000	正常关闭
1001	端点离开（如关闭页面）
1006	异常关闭（未发送 Close）
1011	服务器遇到异常

正常的关闭流程是：一方发 Close 帧，对方回一个 Close 帧，然后双方关闭底层 TCP 连接。如果一方直接断开 TCP 而不发 Close 帧，对方会收到状态码 1006（这是本地的标记，不会出现在网络上）。

四、WebSocket 生命周期

把上面的内容串起来，WebSocket 连接的完整生命周期如下：

1. 连接建立

客户端发起 HTTP 请求，携带 Upgrade: websocket 等头部。
服务器校验请求，返回 101 Switching Protocols。
握手完成，TCP 连接升级为 WebSocket 连接，双方可以开始收发帧。

2. 数据交换

双方按需发送文本帧、二进制帧。
可选地发送 Ping/Pong 保持连接活跃。
大消息可以分片为多个帧发送（continuation 帧）。

3. 连接关闭

一方发送 Close 帧（可携带状态码和原因）。
对方回复 Close 帧。
双方关闭底层 TCP 连接。
应用层收到关闭回调，清理资源。

下面用一个 Go 程序完整模拟这个生命周期（用 net 标准库手动实现握手和帧解析，帮助理解协议细节）：

package main

import (
	"bufio"
	"crypto/sha1"
	"encoding/base64"
	"fmt"
	"net"
	"strings"
)

const guid = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"

func computeAccept(key string) string {
	h := sha1.New()
	h.Write([]byte(key + guid))
	return base64.StdEncoding.EncodeToString(h.Sum(nil))
}

// 解析一个最简的 WebSocket 文本帧（不考虑分片和掩码复杂情况）
func readFrame(r *bufio.Reader) (string, error) {
	first, err := r.ReadByte()
	if err != nil {
		return "", err
	}
	second, err := r.ReadByte()
	if err != nil {
		return "", err
	}
	fin := first&0x80 != 0
	opcode := first & 0x0F
	masked := second&0x80 != 0
	length := int(second & 0x7F)

	var maskKey [4]byte
	if masked {
		if _, err := r.Read(maskKey[:]); err != nil {
			return "", err
		}
	}

	payload := make([]byte, length)
	if _, err := r.Read(payload); err != nil {
		return "", err
	}
	if masked {
		for i := range payload {
			payload[i] ^= maskKey[i%4]
		}
	}

	fmt.Printf("收到帧: FIN=%v opcode=%d len=%d masked=%v\n", fin, opcode, length, masked)
	return string(payload), nil
}

func main() {
	ln, err := net.Listen("tcp", ":9000")
	if err != nil {
		fmt.Println("监听失败:", err)
		return
	}
	fmt.Println("原始 WebSocket 服务器监听 :9000")

	conn, err := ln.Accept()
	if err != nil {
		return
	}
	defer conn.Close()

	// 1. 握手阶段：解析 HTTP 升级请求
	reader := bufio.NewReader(conn)
	var clientKey string
	for {
		line, err := reader.ReadString('\n')
		if err != nil {
			return
		}
		line = strings.TrimSpace(line)
		if line == "" {
			break // 头部结束
		}
		if strings.HasPrefix(line, "Sec-WebSocket-Key:") {
			clientKey = strings.TrimSpace(strings.TrimPrefix(line, "Sec-WebSocket-Key:"))
		}
	}

	// 返回 101 响应
	resp := "HTTP/1.1 101 Switching Protocols\r\n" +
		"Upgrade: websocket\r\n" +
		"Connection: Upgrade\r\n" +
		"Sec-WebSocket-Accept: " + computeAccept(clientKey) + "\r\n\r\n"
	conn.Write([]byte(resp))
	fmt.Println("握手完成")

	// 2. 数据交换阶段：读取客户端发来的帧
	msg, err := readFrame(reader)
	if err != nil {
		fmt.Println("读取帧失败:", err)
		return
	}
	fmt.Println("收到消息:", msg)
}

这个例子没有用任何第三方库，纯用标准库实现了 WebSocket 握手和最简单的帧解析。当然，实际开发中不会这么做（轮子已经造好了），但亲手实现一次能让你彻底理解协议细节。

五、Go 标准库中的 WebSocket

一个常见问题是：Go 标准库里有 WebSocket 吗？答案是没有。

Go 标准库 net/http 提供了 HTTP 服务端和客户端，支持 HTTP/1.1、HTTP/2，但并没有内置 WebSocket 支持。原因是 WebSocket 在握手阶段是 HTTP，但握手完成后的数据帧协议是独立的，标准库没有把这部分纳入。这也是为什么 http.Hijacker 接口存在——它允许你「劫持」底层 TCP 连接，自己实现协议。上面那个原始例子其实就用到了类似的思路。

所以要用 WebSocket，必须借助第三方库。好在 Go 生态有几个成熟的选择。

六、主流 Go WebSocket 库对比

Go 社区有三个主流的 WebSocket 库，各有特点。

1. gorilla/websocket

GitHub 上 Star 数最多、使用最广的 Go WebSocket 库。API 设计清晰，功能完整，文档详尽。许多知名项目（如 Prometheus 的某些组件）都在用它。它提供了 Upgrader 把 HTTP 连接升级为 WebSocket，提供了 Conn 类型封装读写操作，支持 Ping/Pong、Close handler、读写超时等。

优点：生态成熟、资料丰富、API 直观。缺点：性能不是最高的，每个连接通常需要两个 goroutine（一个读、一个写）。适用：绝大多数项目，尤其是入门和中等规模应用。

2. nhooyr/websocket（现名 coder/websocket）

由 Anthropic 工程师（后转由 coder 维护）开发的现代 WebSocket 库，主打「与 context 集成」「API 简洁」「最小化依赖」。它完全用 context.Context 控制读写超时和取消，API 设计更现代。性能接近 gorilla，内存分配更少。

优点：context 原生支持、API 现代、依赖少。缺点：生态资料不如 gorilla 多。适用：偏好现代 API 风格、注重 context 集成的项目。

3. gobwas/ws

由 Mail.ru 团队开源的高性能 WebSocket 库，主打「零内存分配」「极低开销」。它不提供高层封装，而是把帧的读写拆成细粒度的原语，让调用方自己组装。配合 gobwas/pool 等库，可以在百万连接场景下保持极低内存占用。

优点：性能最高、内存分配最少。缺点：API 偏底层，使用复杂，开发效率低。适用：对性能和连接数有极致要求的超大规模应用（如 IM、推送系统）。

对比表

库	性能	易用性	生态	context 集成	适用规模
gorilla/websocket	中高	高	最丰富	弱	中小规模
nhooyr/websocket	高	高	中等	强	中大规模
gobwas/ws	极高	低	较少	自行处理	超大规模

选型建议

学习阶段、中小项目：用 gorilla/websocket，资料最多，踩坑最少。本系列教程后续也以它为主。
新项目、注重现代 API：考虑 nhooyr/websocket，context 集成对超时和取消很友好。
百万连接级 IM/推送：考虑 gobwas/ws，但要做好「自己写更多胶水代码」的准备。

下面用一个简单对比示例展示三个库的「最小服务器」写法差异（仅作风格对比，不展开细节）：

package main

import (
	"fmt"
	"net/http"
)

// 这里只做风格对比说明，实际运行需要各自库的依赖
// 三种库的「最小升级 + 回显」写法差异如下（伪代码示意）：

// gorilla/websocket 风格
func gorillaStyle(w http.ResponseWriter, r *http.Request) {
	// upgrader.Upgrade(w, r, nil) 返回 *Conn
	// 循环 conn.ReadMessage() -> conn.WriteMessage()
	fmt.Println("gorilla: Upgrader + Conn 风格")
}

// nhooyr/websocket 风格
func nhooyrStyle(w http.ResponseWriter, r *http.Request) {
	// websocket.Accept(w, r, nil) 返回 *Conn
	// 循环 conn.Read(ctx) -> conn.Write(ctx, ...)
	fmt.Println("nhooyr: Accept + context 风格")
}

// gobwas/ws 风格
func gobwasStyle(w http.ResponseWriter, r *http.Request) {
	// 需要 http.Hijacker 拿到底层 conn
	// 手动 Upgrade(conn, key)
	// 手动读帧、解掩码、写帧
	fmt.Println("gobwas: Hijack + 手动帧操作风格")
}

func main() {
	// 本示例仅打印三种风格差异，不可直接运行
	fmt.Println("三种主流 Go WebSocket 库风格对比")
}

可以看到，同样是「升级 + 回显」，三个库的抽象层次和 API 风格差异很大。本系列后续将从 gorilla/websocket 入手，逐步深入。

七、小结

本篇我们从「为什么需要 WebSocket」出发，对比了 HTTP 与 WebSocket 的本质差异，梳理了轮询、长轮询、SSE、WebSocket 四种实时通信方案的特点。然后深入 WebSocket 协议本身：握手如何复用 HTTP Upgrade、数据帧的 FIN/opcode/mask 字段含义、文本帧与二进制帧的区别、Ping/Pong 心跳的作用、Close 帧的优雅关闭流程。最后我们梳理了 WebSocket 连接的完整生命周期，并用标准库手动实现了一个最简的 WebSocket 服务器来印证协议细节。

关键要点回顾：

WebSocket 是为全双工、低开销实时通信设计的协议，建立在 HTTP 握手之上。
握手用 HTTP Upgrade 机制，服务器返回 101 后切换为帧协议。
数据帧由 FIN、opcode、mask、payload 等字段构成，客户端帧必须掩码。
Ping/Pong 用于保活和探活，Close 帧用于优雅关闭。
Go 标准库不含 WebSocket，主流选择是 gorilla/websocket、nhooyr/websocket、gobwas/ws。

下一篇我们将正式上手 gorilla/websocket，学习 Upgrader、消息收发、心跳、超时、并发安全等核心 API，并实现一个完整的 Echo 服务器。

入门篇

进阶篇

资深篇

WebSocket 协议与原理

一、为什么需要 WebSocket

二、HTTP vs WebSocket

1. 请求-响应 vs 全双工

2. 轮询、长轮询、SSE、WebSocket 对比

3. 一个直观的对比示例

三、WebSocket 协议详解

1. 握手过程：HTTP Upgrade

2. 数据帧格式：FIN、opcode、mask

3. 文本帧 vs 二进制帧

4. Ping/Pong 心跳

5. Close 帧

四、WebSocket 生命周期

1. 连接建立

2. 数据交换

3. 连接关闭

五、Go 标准库中的 WebSocket

六、主流 Go WebSocket 库对比

1. gorilla/websocket

2. nhooyr/websocket（现名 coder/websocket）

3. gobwas/ws

对比表

选型建议

七、小结

WebSocket 协议与原理 ​

一、为什么需要 WebSocket ​

二、HTTP vs WebSocket ​

1. 请求-响应 vs 全双工 ​

2. 轮询、长轮询、SSE、WebSocket 对比 ​

3. 一个直观的对比示例 ​

三、WebSocket 协议详解 ​

1. 握手过程：HTTP Upgrade ​

2. 数据帧格式：FIN、opcode、mask ​

3. 文本帧 vs 二进制帧 ​

4. Ping/Pong 心跳 ​

5. Close 帧 ​

四、WebSocket 生命周期 ​

1. 连接建立 ​

2. 数据交换 ​

3. 连接关闭 ​

五、Go 标准库中的 WebSocket ​

六、主流 Go WebSocket 库对比 ​

1. gorilla/websocket ​

2. nhooyr/websocket（现名 coder/websocket） ​

3. gobwas/ws ​

对比表 ​

选型建议 ​

七、小结 ​

WebSocket 协议与原理

一、为什么需要 WebSocket

二、HTTP vs WebSocket

1. 请求-响应 vs 全双工

2. 轮询、长轮询、SSE、WebSocket 对比

3. 一个直观的对比示例

三、WebSocket 协议详解

1. 握手过程：HTTP Upgrade

2. 数据帧格式：FIN、opcode、mask

3. 文本帧 vs 二进制帧

4. Ping/Pong 心跳

5. Close 帧

四、WebSocket 生命周期

1. 连接建立

2. 数据交换

3. 连接关闭

五、Go 标准库中的 WebSocket

六、主流 Go WebSocket 库对比

1. gorilla/websocket

2. nhooyr/websocket（现名 coder/websocket）

3. gobwas/ws

对比表

选型建议

七、小结