前置阅读：网络-15 HTTP 版本演进

1. 单工、半双工、全双工

先厘清三个基础术语，后面反复要用：

• 单工：信息只能单向传送。如广播、遥控器。
• 半双工：能双向传送，但不能同时。如对讲机——一方说话时另一方只能听。
• 全双工：能够同时双向传送。如电话。

HTTP 的问题就在这里：它是请求-响应模型，通信只能由客户端发起，服务器无法主动推送。WebSocket 解决的正是这个问题。

2. 概述

HTML5 开始提供的一种浏览器与服务器进行全双工通讯的网络技术，属于应用层协议。它基于 TCP 传输协议，并复用 HTTP 的握手通道。

说到优点，这里的对比参照物是 HTTP 协议，概括地说就是：支持双向通信，更灵活，更高效，可扩展性更好。

1）支持双向通信，实时性更强。WebSocket 的默认端口也选择了 80 和 443，因为现在互联网上的防火墙屏蔽了绝大多数的端口，只对 HTTP 的 80、443 端口“放行”。

2）更好的二进制支持。WebSocket 采用了二进制帧结构，语法、语义与 HTTP 完全不兼容，但因为它的主要运行环境是浏览器，为了便于推广和应用，就不得不“搭便车”，在使用习惯上尽量向 HTTP 靠拢，这就是它名字里“Web”的含义。

3）较少的控制开销。连接创建后，ws 客户端、服务端进行数据交换时，协议控制的数据包头部较小。在不包含头部的情况下，服务端到客户端的包头只有 2~10 字节（取决于数据包长度），客户端到服务端的的话，需要加上额外的 4 字节的掩码。而 HTTP 协议每次通信都需要携带完整的头部；

4）支持扩展。ws 协议定义了扩展，用户可以扩展协议，或者实现自定义的子协议。（比如支持自定义压缩算法等）。WebSocket 没有使用 TCP 的“IP 地址 + 端口号”，而是延用了 HTTP 的 URI 格式，但开头的协议名不是“http”，引入的是两个新的名字：“ws”和“wss”，分别表示明文和加密的 WebSocket 协议。

3. 如何建立连接

前面提到，WebSocket 复用了 HTTP 的握手通道。具体指的是，客户端通过 HTTP 请求与 WebSocket 服务端协商升级协议。协议升级完成后，后续的数据交换则遵照 WebSocket 的协议。

3.1 客户端申请协议升级

首先，客户端发起协议升级请求。可以看到，采用的是标准的 HTTP 报文格式，且只支持 GET 方法。

GET / HTTP/1.1

Host: localhost:8080

Origin:http: //127.0.0.1:3000

Connection: Upgrade

Upgrade: websocket

Sec-WebSocket-Version: 13

Sec-WebSocket-Key: w4v7O6xFTi36lq3RNcgctw==

重点请求首部意义如下：

1）Connection: Upgrade：表示要升级协议；

2）Upgrade: websocket：表示要升级到 websocket 协议；

3）Sec-WebSocket-Version: 13：表示 websocket 的版本。如果服务端不支持该版本，需要返回一个 Sec-WebSocket-Versionheader，里面包含服务端支持的版本号；

4）Sec-WebSocket-Key：与后面服务端响应首部的 Sec-WebSocket-Accept 是配套的，提供基本的防护，比如恶意的连接，或者无意的连接。

注意：上面请求省略了部分非重点请求首部。由于是标准的 HTTP 请求，类似 Host、Origin、Cookie 等请求首部会照常发送。在握手阶段，可以通过相关请求首部进行 安全限制、权限校验等

3.2 服务端响应协议升级

服务端返回内容如下，状态代码 101 表示协议切换。到此完成协议升级，后续的数据交互都按照新的协议来。

HTTP/1.1 101 Switching Protocols

Connection:Upgrade

Upgrade: websocket

Sec-WebSocket-Accept: Oy4NRAQ13jhfONC7bP8dTKb4PTU=

Sec-WebSocket-Accept 的计算 Sec-WebSocket-Accept 根据客户端请求首部的 Sec-WebSocket-Key 计算出来。

计算公式为：

1）将 Sec-WebSocket-Key 跟 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 拼接；

2）通过 SHA1 计算出摘要，并转成 base64 字符串。

伪代码如下：

toBase64( sha1( Sec-WebSocket-Key + 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 ) )

4. websocket帧格式

客户端、服务端数据的交换，离不开数据帧格式的定义。因此，在实际讲解数据交换之前，我们先来看下 WebSocket 的数据帧格式。

WebSocket 客户端、服务端通信的最小单位是帧（frame），由 1 个或多个帧组成一条完整的消息（message）。

1）发送端：将消息切割成多个帧，并发送给服务端；

2）接收端：接收消息帧，并将关联的帧重新组装成完整的消息。

1）FIN：1 个比特。

如果是 1，表示这是消息（message）的最后一个分片（fragment），如果是 0，表示不是是消息（message）的最后一个分片（fragment）。

2）RSV1, RSV2, RSV3：各占 1 个比特。

一般情况下全为 0。当客户端、服务端协商采用 WebSocket 扩展时，这三个标志位可以非 0，且值的含义由扩展进行定义。如果出现非零的值，且并没有采用 WebSocket 扩展，连接出错。

3）Opcode：4 个比特。

操作代码，Opcode 的值决定了应该如何解析后续的数据载荷（data payload）。如果操作代码是不认识的，那么接收端应该断开连接（fail the connection）。

可选的操作代码如下：

%x0：表示一个延续帧。当 Opcode 为 0 时，表示本次数据传输采用了数据分片，当前收到的数据帧为其中一个数据分片。

%x1：表示这是一个文本帧（frame）

%x2：表示这是一个二进制帧（frame）

%x3-7：保留的操作代码，用于后续定义的非控制帧。

%x8：表示连接断开。

%x9：表示这是一个 ping 操作。

%xA：表示这是一个 pong 操作。

%xB-F：保留的操作代码，用于后续定义的控制帧。

4）Mask：1 个比特。

表示是否要对数据载荷进行掩码操作。从客户端向服务端发送数据时，需要对数据进行掩码操作；从服务端向客户端发送数据时，不需要对数据进行掩码操作。

如果服务端接收到的数据没有进行过掩码操作，服务端需要断开连接。

如果 Mask 是 1，那么在 Masking-key 中会定义一个掩码键（masking key），并用这个掩码键来对数据载荷进行反掩码。所有客户端发送到服务端的数据帧，Mask 都是 1。

掩码的算法、用途在下一小节讲解。

5）Payload length：数据载荷的长度，单位是字节。为 7 位，或 7+16 位，或 7+64 位。

假设数 Payload length === x，如果：

x 为 0~125：数据的长度为 x 字节。

x 为 126：后续 2 个字节代表一个 16 位的无符号整数，该无符号整数的值为数据的长度。

x 为 127：后续 8 个字节代表一个 64 位的无符号整数（最高位为 0），该无符号整数的值为数据的长度。

此外，如果 payload length 占用了多个字节的话，payload length 的二进制表达采用网络序（big endian，重要的位在前）。

6）Masking-key：0 或 4 字节（32 位）

所有从客户端传送到服务端的数据帧，数据载荷都进行了掩码操作，Mask 为 1，且携带了 4 字节的 Masking-key。如果 Mask 为 0，则没有 Masking-key。

备注：载荷数据的长度，不包括 mask key 的长度。

7）Payload data：(x+y) 字节

载荷数据：包括了扩展数据、应用数据。其中，扩展数据 x 字节，应用数据 y 字节。

扩展数据：如果没有协商使用扩展的话，扩展数据数据为 0 字节。所有的扩展都必须声明扩展数据的长度，或者可以如何计算出扩展数据的长度。此外，扩展如何使用必须在握手阶段就协商好。如果扩展数据存在，那么载荷数据长度必须将扩展数据的长度包含在内。

应用数据：任意的应用数据，在扩展数据之后（如果存在扩展数据），占据了数据帧剩余的位置。载荷数据长度 减去 扩展数据长度，就得到应用数据的长度。

5. 数据传输

一旦 WebSocket 客户端、服务端建立连接后，后续的操作都是基于数据帧的传递。

WebSocket 根据 opcode 来区分操作的类型。比如 0x8 表示断开连接，0x0-0x2 表示数据交互。

数据分片

WebSocket 的每条消息可能被切分成多个数据帧。当 WebSocket 的接收方收到一个数据帧时，会根据 FIN 的值来判断，是否已经收到消息的最后一个数据帧。

FIN=1 表示当前数据帧为消息的最后一个数据帧，此时接收方已经收到完整的消息，可以对消息进行处理。FIN=0，则接收方还需要继续监听接收其余的数据帧。

此外，opcode 在数据交换的场景下，表示的是数据的类型。0x01 表示文本，0x02 表示二进制。而 0x00 比较特殊，表示延续帧（continuation frame），要和前面的合一块。

来个例子：

第一条消息：

FIN=1, 表示是当前消息的最后一个数据帧。服务端收到当前数据帧后，可以处理消息。opcode=0x1，表示客户端发送的是文本类型。

第二条消息：

1）FIN=0，opcode=0x1，表示发送的是文本类型，且消息还没发送完成，还有后续的数据帧；

2）FIN=0，opcode=0x0，表示消息还没发送完成，还有后续的数据帧，当前的数据帧需要接在上一条数据帧之后；

3）FIN=1，opcode=0x0，表示消息已经发送完成，没有后续的数据帧，当前的数据帧需要接在上一条数据帧之后。服务端可以将关联的数据帧组装成完整的消息。

Client: FIN=1, opcode=0x1, msg=“hello”

Server: (process complete message immediately) Hi.

Client: FIN=0, opcode=0x1, msg=“and a”

Server: (listening, new message containing text started)

Client: FIN=0, opcode=0x0, msg=“happy new”

Server: (listening, payload concatenated to previous message)

Client: FIN=1, opcode=0x0, msg=“year!”

Server: (process complete message) Happy new year to you too!

6. WebSocket 和 Socket 的区别

这两个名字长得像，但完全不是一个层面的东西，是初学者最容易混淆的一组概念：

一个便于记忆的类比：HTTP 和 Socket 是什么关系，WebSocket 和 Socket 就是什么关系。 HTTP 是协议，Socket 是实现这个协议时用的 API；WebSocket 同样是协议，底层照样通过 Socket 这套 API 来收发数据。

Socket 本身详见 网络-20 Socket 编程与 IO 模型。

7. 与轮询、长轮询、SSE 的对比

实现"服务端推送"其实有好几条路，WebSocket 只是其中一种，选型时要看场景：

SSE（Server-Sent Events）常被忽略，但很多场景下它比 WebSocket 更合适：

• 它就是一个 Content-Type: text/event-stream 的普通 HTTP 响应，天然穿透代理和防火墙，不需要协议升级；
• 浏览器端 EventSource 自带断线重连，还支持 Last-Event-ID 断点续传，这两件事用 WebSocket 都得自己写；
• 缺点是只能服务端推客户端，且（在 HTTP/1.1 下）受浏览器每域名 6 连接限制。

判断标准很简单：只需要服务端推送就用 SSE，需要客户端也高频发消息才用 WebSocket。 现在常见的大模型流式输出用的就是 SSE，而不是 WebSocket。

8. 心跳保活与断线重连

这是生产环境必须处理、而协议本身不管的两件事。

为什么需要心跳？ 连接可能已经"死了"而双方都不知道——中间的 NAT 网关或负载均衡器有空闲超时（通常几十秒到几分钟），会静默丢弃长时间无数据的连接映射，不发任何通知。此时双方的 socket 看起来还是 ESTABLISHED，实际上数据已经发不过去了。

WebSocket 协议为此定义了 Ping（0x9）/ Pong（0xA）控制帧。Go 里用 gorilla/websocket 的典型写法：

const (
    pongWait   = 60 * time.Second      // 多久没收到 pong 就认为连接已死
    pingPeriod = 54 * time.Second      // 必须小于 pongWait，留出容错
)

// 读协程：每收到一个 pong 就把读超时往后推
func readLoop(conn *websocket.Conn) {
    conn.SetReadDeadline(time.Now().Add(pongWait))
    conn.SetPongHandler(func(string) error {
        return conn.SetReadDeadline(time.Now().Add(pongWait))
    })
    for {
        _, msg, err := conn.ReadMessage()
        if err != nil {
            log.Println("连接断开:", err)   // 触发上层重连
            return
        }
        handle(msg)
    }
}

// 写协程：定时发 ping。注意 gorilla 的 Conn 不支持并发写，
// 所有写操作（业务消息 + ping）必须集中在同一个 goroutine 里
func writeLoop(conn *websocket.Conn, send <-chan []byte) {
    ticker := time.NewTicker(pingPeriod)
    defer ticker.Stop()
    for {
        select {
        case msg := <-send:
            if err := conn.WriteMessage(websocket.TextMessage, msg); err != nil {
                return
            }
        case <-ticker.C:
            if err := conn.WriteControl(websocket.PingMessage, nil,
                time.Now().Add(10*time.Second)); err != nil {
                return
            }
        }
    }
}

两个容易踩的坑：

1. gorilla/websocket 的连接不支持并发写，两个 goroutine 同时 WriteMessage 会 panic。标准做法就是上面这样：所有写集中到一个 writeLoop，业务通过 channel 投递。
2. pingPeriod 必须小于 pongWait，否则还没等到对方回 pong 就先自己超时了。

断线重连要注意用指数退避，避免服务端重启时几万个客户端同时重连把它再打挂：

backoff := time.Second
for {
    conn, _, err := websocket.DefaultDialer.Dial(url, nil)
    if err != nil {
        time.Sleep(backoff)
        if backoff < 30*time.Second {
            backoff *= 2          // 1s → 2s → 4s ... 上限 30s
        }
        continue
    }
    backoff = time.Second         // 成功后重置
    serve(conn)                   // 阻塞直到断开
}

9. 关闭握手

WebSocket 有自己的关闭流程，不是直接扯断 TCP：一方发送 Close 帧（0x8），对方回一个 Close 帧，然后才关闭 TCP 连接。Close 帧可以携带状态码：

1006 是排障时最常见的一个：它不会出现在网络传输里（协议规定不能发送 1006），而是浏览器/客户端库在"连接没有正常关闭握手就断了"时本地生成的。看到 1006 基本可以判定是网络中断、代理超时或服务端进程被杀，而不是业务逻辑主动关闭。

Nginx 反向代理 WebSocket 必须显式转发升级头，否则握手会失败：

location /ws {
    proxy_pass http://backend;
    proxy_http_version 1.1;                      # 必须 1.1，1.0 不支持 Upgrade
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 300s;                     # 默认 60s，比心跳间隔长
}

proxy_read_timeout 要设得比心跳间隔长，否则 Nginx 会在心跳到达前就先掐断连接——这是 WebSocket 上线后"连接每 60 秒断一次"最常见的原因。

10. 本章面试题

proxy_http_version 1.1;              # 必须 1.1，1.0 不支持 Upgrade
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 300s;             # ★ 要大于心跳间隔