---
tags: [gRPC, HTTP/2, Protocol, Go, Networking]
create time: 2026-05-11 16:42
---

# HTTP/2 传输原理

## 概述

gRPC 跑在 HTTP/2 之上，这意味着你天然享受 HTTP/2 带来的所有性能红利：多路复用、头部压缩、服务器推送。但也带来了一些新的心智负担——原来用 TCP 协议栈就能搞定的事，现在又多了一层帧（frame）和流（stream）的概念。理解底层原理才能调试那些"偶发性超时""连接无故断开"的问题。

> [!question] 为什么 gRPC 不用 HTTP/1.1？
> HTTP/1.1 的串行阻塞模型在面对高并发微服务时效率太低——每增加一个并发都要付出一次 TCP 握手开销。而 HTTP/2 在一个 TCP 连接上就能搞定任意数量的并发请求。但代价是你得适应全新的二进制协议层。

> [!tip] 先搞清楚这层关系
> ```
> 应用层：Protobuf 消息 → 序列化为字节流
> gRPC 层：把字节流包装成 request/response/stream
> HTTP/2 层：把 gRPC 数据切分成 frame， multiplex 到 stream 上
> TCP 层：可靠的字节流传输
> ```
> gRPC = Protobuf wire format + HTTP/2 transport + gRPC semantics

## HTTP/2 vs HTTP/1.1 对比

| 特性 | HTTP/1.1 | HTTP/2 |
|------|----------|--------|
| 连接数 | 每主机通常 6 个 | 任意数量 |
| 传输格式 | 纯文本 | 二进制 |
| 多路复用 | ❌ (head-of-line blocking) | ✅ |
| 头部压缩 | ❌ | ✅ HPACK |
| 服务器推送 | ❌ | ✅ PushPromise |
| 头部顺序 | 明文逐行发送 | header block fragments |

**核心差异一句话：**HTTP/2 将一切变成了二进制帧（frame），用帧的组合来表达请求、响应和元数据。

> [!note] 为什么二进制更好？
> 纯文本协议（如 HTTP/1.1）需要靠 `\r\n` 分隔，解析容易出错且浪费带宽。二进制协议用 length + type 字段精确定位每个单元，解析更快也更健壮。代价是——你不能再直接用浏览器看明文了，必须用专门的抓包工具。

## HTTP/2 连接建立过程

### Connection Preface（连接前置声明）

HTTP/2 要求在真正的数据交换之前，双方先发一段 "preface" 来确认对方支持 HTTP/2：

```go
// Client Preface（客户端必须首先发送，固定字符串）
// PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n
// SETTINGS frame (length = 0)

// Server Preface（服务端确认后回复同样长度的 SETTINGS frame）
// SETTINGS frame (length = 0)
```

这不是什么代码层面的操作——gRPC 客户端内部自动处理。但你可以在 Wireshark 中看到这个 handshake 过程：Client 发 `PRI * HTTP/2.0`，Server 回复 `SETTINGS ACK`，然后双方才开始交换业务数据。

> [!warning] 常见坑
> 某些老旧代理（如旧版 Squid / Nginx < 1.3.10）不支持 ALPN 或不认 Preface，会导致 HTTP/2 降级为 HTTP/1.1。遇到偶发的 "connection reset" 时可以检查一下中间件版本。

### TLS Handshake + ALPN

如果是 HTTPS 连接（gRPC 生产环境的标配），完整的握手流程是：

```mermaid
sequenceDiagram
    participant C as Client
    participant T as TCP/TLS
    participant S as Server

    Note over C,S: Step 1 — TCP 三次握手
    C->>T: SYN
    T->>S: SYN-ACK
    S->>C: ACK

    Note over C,T: Step 2 — TLS 1.3 握手
    C->>T: ClientHello (ALPN: h2)
    T->>S: ServerHello (selected: h2)
    S->>C: finished

    Note over C,S: Step 3 — HTTP/2 Preface
    C->>S: ClientPreface + SETTINGS
    S->>C: SETTINGS ACK + ServerSettings

    Note over C,S: Step 4 — 开始 multiplexing
    C->>S: HEADERS + DATA (Stream 1)
    C->>S: HEADERS + DATA (Stream 3)
    S->>C: HEADERS + DATA (Stream 2)
```

关键点是 **ALPN（Application-Layer Protocol Negotiation）**：TLS 握手的 `ClientHello` 中会附带支持的协议列表（`h2` / `http/1.1`），服务端从中选择一个并在 `ServerHello` 中返回。如果协商失败，就不会走 HTTP/2。

## HTTP/2 帧（Frame）详解

gRPC 的数据以 frame 为单位在连接上传输。每种 frame 有特定的类型码和控制语义：

| Frame | Type Code | 作用 | gRPC 中的场景 |
|-------|-----------|------|---------------|
| DATA | 0x0 | 实际载荷 | Request / Response body |
| HEADERS | 0x1 | 头信息（含 HTTP/2 header block） | HTTP headers + gRPC metadata |
| PRIORITY | 0x2 | 设置 stream 优先级 | gRPC 不使用 |
| RST_STREAM | 0x3 | 异常终止 | Client/Server 主动中断流 |
| SETTINGS | 0x4 | 协商参数 | 握手阶段交换 max_concurrent_streams 等 |
| PUSH_PROMISE | 0x5 | 服务器推送 | gRPC 不使用 |
| PING | 0x6 | 保活探测 | keepalive ping |
| GOAWAY | 0x7 | 优雅关闭 | Server 准备停机 |
| WINDOW_UPDATE | 0x8 | 流量控制 | 调整接收窗口大小 |
| CONTINUATION | 0x9 | 续传 header block | 头部太长时的分片传输 |

每个 frame 的结构固定为 9 字节头部 + 有效载荷：

```
+-----------------------------------------------+
| Length (24 bits)                               |
+---------------+---------------+---------------+
| Type (8 bits)  | R(1 bit)    | Stream ID(31 bits) |
+---------------+---------------+---------------+
| Payload (... bytes)                            |
+-----------------------------------------------+
```

- **Length**: payload 长度，最大 2^24 - 1 ≈ 16MB
- **Type**: frame 类型（上述表格中的 Type Code）
- **R**: reserved bit，必须为 0
- **Stream ID**: 所属 stream 的 ID，0 表示 connection-level frame
- **Payload**: 随类型不同含义各异

```mermaid
flowchart TB
    subgraph Connection ["HTTP/2 Connection"]
        direction TB
        Streams --> S1["Stream 1<br/>HEADERS → DATA → HEADERS → DATA"]
        Streams --> S2["Stream 2<br/>HEADERS → DATA"]
        Streams --> SN["Stream N<br/>HEADERS → DATA"]
    end

    ConnLevel -.-> Settings["SETTINGS / PING / GOAWAY<br/>(Stream ID = 0)"]

    style ConnLevel fill:#A0AEC0,color:#fff
    style Settings fill:#ED8936,color:#fff
    style S1 fill:#00B6BC,color:#fff
    style S2 fill:#4FC08D,color:#fff
    style SN fill:#FFD43B
```

**关键概念：**
- 每个 connection 上有多个 stream，每个 stream 独立收发 data
- 所有的 frame 都属于某个 stream（除了 connection-level 的 SETTINGS/GOAWAY/PING/WINDOW_UPDATE）
- gRPC 只用了其中一小部分 frame 类型——它把复杂的 protocol 封装在了内部

## Stream 与 Multiplexing

这是 HTTP/2 最重要的特性，也是 gRPC 高性能的核心原因。

**机制：**
- 一个 TCP 连接上可以有多个 stream
- 每个 stream 有唯一的 stream ID（奇数 = client 发起，偶数 = server 发起，ID 从 1 开始递增）
- stream 之间互不干扰——解决了 HTTP/1.1 的队头阻塞（head-of-line blocking）

### Stream ID 分配规则

```mermaid
flowchart LR
    Client["Client"] --- TCP[("TCP Connection")]
    TCP --- Server["Server"]

    subgraph Streams ["Stream IDs"]
        S1["1<br/>Client→Server<br/>Unary call"]
        S3["3<br/>Client→Server<br/>Another call"]
        S5["5<br/>Client→Server<br/>Streaming"]
        S2["2<br/>Server→Client<br/>Response to #1"]
        S4["4<br/>Server→Client<br/>Response to #3"]
        S6["6<br/>Server→Client<br/>Push error"]
    end

    Client --> S1
    Client --> S3
    Client --> S5
    Server --> S2
    Server --> S4
    Server --> S6

    style S1 fill:#00B6BC,color:#fff
    style S3 fill:#00B6BC,color:#fff
    style S5 fill:#00B6BC,color:#fff
    style S2 fill:#4FC08D,color:#fff
    style S4 fill:#4FC08D,color:#fff
    style S6 fill:#4FC08D,color:#fff
```

**要点：**
- Stream ID 严格递增，Client 永远用奇数，Server 永远用偶数
- 即使一个 stream 已经完成（发送了 END_STREAM flag），它的 ID 也不会回收重用
- 理论上单条连接最多可以有 2^31 个 stream（受 Stream ID 字段限制）

### 代码示例

同一个 conn 上可以并发创建多个 stream，无需额外 TCP 连接：

```go
conn, _ := grpc.Dial("localhost:50051", ...) // 只有一个 TCP 连接
client := pb.NewUserServiceClient(conn)

// 这三个 call 在同一个连接的不同 stream 上并行执行
go client.GetUser(ctx1, &pb.GetUserRequest{Id: 1}) // → Stream 1
go client.GetUser(ctx2, &pb.GetUserRequest{Id: 2}) // → Stream 3
go client.GetUser(ctx3, &pb.GetUserRequest{Id: 3}) // → Stream 5
```

## HPACK 头部压缩

HTTP/2 使用 HPACK 算法对头部进行压缩，主要靠两个手段：

1. **静态字典** — RFC 预定义了 61 个常用 header（如 `:method`, `:path`, `content-type`），直接通过索引引用
2. **动态表** — 运行时新增的 key-value 对会被缓存，后续请求只需引用索引号
3. **Huffman 编码** — 对无法查表的字符串做变长编码

gRPC 强制要求 hpack table size >= 4096 bytes。好处是 gRPC 的请求头部通常只有几十个字节，相比 HTTP/1.1 每次都要带完整的 User-Agent/Content-Type 等大很多倍。

```mermaid
flowchart LR
    A["原始 Header:<br/>:method=POST<br/>:path=/user.v1.UserService/CreateUser<br/>content-type=application/grpc<br/>grpc-timeout=30s"] --> B["HPACK Encoder"]

    B -->|"索引引用"| D[":method → :POST (static table idx 2)"]
    B -->|"动态表插入"| E[":path → full string<br/>(dynamic table idx 1)"]
    B -->|"Huffman 编码"| F["grpc-timeout=30s<br/>(Huffman: 5 bytes)"]

    D --> G["Header Block Fragment<br/>(~15 bytes)"]
    E --> G
    F --> G

    style A fill:#FFD43B
    style B fill:#00B6BC,color:#fff
    style G fill:#4FC08D,color:#fff
```

> [!example] HPACK 的实际压缩效果
>
> ```
> // HTTP/1.1 头部（每次完整发送，约 200+ bytes）
> POST /user.v1.UserService/CreateUser HTTP/1.1
> Host: localhost:50051
> Content-Type: application/grpc
> Grpc-Timeout: 30s
> User-Agent: grpc-go/1.50.0
> Te: trailers
>
> // HTTP/2 + HPACK（连续多次调用，压缩后可能只剩十几字节）
> HEADERS: {idx 2} {dynamic-table: :path=/user.v1.UserService/CreateUser} {huffman: 30s}
> DATA: <protobuf payload>
> ```
>
> 注意第二次调用时，`:method=POST` 和 `content-type=application/grpc` 都可以直接从 static table 引用——不需要再发送这些字符串。

## Flow Control 流量控制

HTTP/2 有两层 flow control，各自独立工作：

| 层级 | 范围 | 默认窗口 | 控制方式 |
|------|------|----------|----------|
| Connection Level | 整个 TCP 连接 | 65535 bytes | WINDOW_UPDATE frame |
| Stream Level | 单个 stream | 继承 connection level | WINDOW_UPDATE frame |

当接收方缓冲区快满时，发送方会收到 WINDOW_UPDATE 被"堵住"——这就是 HTTP/2 的 **backpressure**。gRPC 在此基础上又加了一层自己的 flow control：

| gRPC 配置项 | 说明 | 默认值 |
|-------------|------|--------|
| `MaxReceiveMessageSize` | 单次可接收的最大消息 | **4 MB** |
| `MaxSendMessageSize` | 单次可发送的最大消息 | math.MaxInt32 |

> [!warning] 这是一个常见的坑！
> 当你的 protobuf message 超过 4MB 时，你会看到类似这样的错误：
> ```
> grpc: received message larger than max (5242880 vs 4194304) on XXX
> ```
> 修复方式：在 dial 或 server 选项中设置更大的 limit。
> ```go
> grpc.WithDefaultCallOptions(grpc.MaxCallRecvMsgSize(10*1024*1024))
> ```
> 注意：这里设置的单位是 bytes。设太大也有风险——对方可能发一个巨型 payload 打爆你的内存。

### 与 HTTP/2 Flow Control 的关系

很多人会把两层 flow control 混淆。简单理解：

- **HTTP/2 Window** 管的是「网络缓冲区」——防止发送方压垮接收方的 TCP 队列
- **gRPC Message Size** 管的是「应用层内存」——防止 protobuf unmarshal 时 OOM

两层都配好了才是真正的安全。

> [!tip] 调优建议
> - HTTP/2 Window：大多数场景不需要手动改，除非出现大量 WINDOW_UPDATE 延迟
> - MaxReceiveMessageSize：按业务需要设定，但不要设为无上限；配合上游 LB 的 payload limit 一起考虑

## 连接生命周期

```mermaid
stateDiagram-v2
    [*] --> Idle
    Idle --> Connecting: TCP connect
    Connecting --> Connected: OK
    Connecting --> ErrorFailed: Failed
    ErrorFailed --> Closed

    Connected --> TLSEncrypted: TLS + ALPN (if secure)
    Connected --> Plaintext: Insecure mode

    TLSEncrypted --> SettingsSent: Send HTTP/2 Preface + SETTINGS
    Plaintext --> SettingsSent: Send HTTP/2 Preface + SETTINGS

    SettingsSent --> Ready: Receive SETTINGS ACK
    SettingsSent --> ErrorSettingsTimeout: Timeout
    ErrorSettingsTimeout --> Closed

    Ready --> Active: Create Streams
    Active --> HalfClose: Stream done (END_STREAM)
    HalfClose --> GoAwayReceived: Server sends GOAWAY
    GoAwayReceived --> DrainPending: Wait for active streams
    DrainPending --> Closed: All pending done

    state Active {
        StreamOpen --> Sending
        StreamOpen --> Receiving
        Sending --> Done
        Receiving --> Done
    }

    note right of ErrorFailed
        DNS 解析失败
        TCP connect timeout
        TLS cert invalid
    end note

    note right of ErrorSettingsTimeout
        对方未在规定时间内
        回复 SETTINGS ACK
    end note
```

**各阶段要点：**

1. **Connecting** — TCP 三次握手。如果目标地址不可达或被防火墙拦截，会在这里报 `connection refused`
2. **TLS + ALPN** — 对于 secure 连接，先用 TLS 加密并协商出 `h2` 协议。证书过期或 host mismatch 会在这一步失败
3. **Settings exchange** — 双方交换 window size、max concurrent streams 等参数。这是 HTTP/2 的正式握手点
4. **Ready** — 可以开始创建 stream 了
5. **Active** — 正常业务阶段，stream 可随时创建和销毁
6. **GOAWAY** — 服务端通知即将关闭（如滚动重启）。已创建的 stream 还能继续完成，新 stream 不能再用这条连接
7. **Closed** — 连接彻底关闭，下次调用时 gRPC 会自动重连（reconnect policy）

> [!note] GOAWAY vs RST_STREAM 的区别
> - **GOAWAY**: connection-level，告诉对方"这条连接以后不能新建 stream 了"，属于优雅关闭
> - **RST_STREAM**: stream-level，仅终止单个 stream，不影响同连接上的其他 stream

## 对开发者的实际影响

### 1. 连接数管理

不需要手动连接池。gRPC 的 `grpc.ClientConn` 已经做了连接复用和自动重建：

```go
// 一个 conn 对象就够了，内部自动管理连接数和重连
conn, _ := grpc.Dial("target", grpc.WithTransportCredentials(...))
// 所有 client share this conn
client1 := pb.NewService1Client(conn)
client2 := pb.NewService2Client(conn)
```

> [!tip] 连接池误区
> 很多从 HTTP/1.1 转过来的开发者会习惯性建连接池。但在 gRPC 里一个 `Dial` 就够——gRPC 内部维护了一个连接管理器，会根据负载情况自动增减连接。

### 2. Keepalive 配置

生产环境务必调优 keepalive 参数，否则可能被负载均衡器或 K8s ingress 切断连接：

```go
grpc.WithKeepaliveParams(keepalive.ClientParameters{
    Time:                10 * time.Second,
    Timeout:             5 * time.Second,
    PermitWithoutStream: true,  // 即使没有 active stream 也发 ping
})

grpc.KeepaliveParams(keepalive.ServerParameters{
    Time:    10 * time.Second, // PING 间隔
    Timeout: 20 * time.Second, // 无响应则断开
})
```

> [!warning] PermitWithoutStream 的作用
> 当这个值为 false 时（默认），如果当前没有任何活跃的 RPC（比如空闲等待期），gRPC 不会发 keepalive ping——此时中间设备恰好会杀掉空闲连接。生产环境建议设为 true。

生产环境的推荐配置取决于你的中间件策略：

| 组件 | 典型 idle timeout | 建议 keepalive Time |
|------|-------------------|---------------------|
| AWS ALB | 60s | 25s |
| Nginx proxy_pass | 75s (proxy_read_timeout) | 30s |
| K8s kube-proxy (iptables) | 根据 conntrack | 25s |
| Cloud Load Balancer | varies | 20–30s |

### 3. MaxMessageSize

遇到 `"message too large"` 错误时，第一反应应该是检查这个限制，而不是怀疑代码逻辑。

### 4. 调试技巧

| 工具 | 用途 | 常用命令 |
|------|------|----------|
| `grpcurl` | CLI 工具，支持直接调用 gRPC 方法 | `grpcurl -plaintext -d '{"id": 42}' localhost:50051 user.v1.UserService.GetUser` |
| `nghttp` | HTTP/2 抓包分析，能看到 frame 级别细节 | `nghttp -v http://localhost:50051` |
| Wireshark | 原始帧级别的诊断 | filter: `tcp.port == 50051 && http2` |
| `GRPC_VERBOSITY=DEBUG GRPC_TRACE=all` | Go 内置的 verbose trace，打印内部事件 | `export GRPC_VERBOSITY=DEBUG && export GRPC_TRACE=http2,transport,subchannel` |

```bash
# 快速测试一个 gRPC endpoint
grpcurl -plaintext -d '{"id": 42}' localhost:50051 user.v1.UserService.GetUser

# 查看服务提供的全部方法
grpcurl -plaintext localhost:50051 list

# 查看某个 service 的详细定义
grpcurl -plaintext localhost:50051 describe user.v1.UserService
```

### 5. 常见问题排查速查表

| 现象 | 可能原因 | 排查方向 |
|------|---------|---------|
| 偶发性 `DEADLINE_EXCEEDED` | HTTP/2 Window 满了被 backpressure 堵住 | Wireshark 看 WINDOW_UPDATE 延迟 |
| 连接间歇性断开 | Keepalive 没开或时间太长，LB 杀了空闲连接 | 检查 `PermitWithoutStream` 和 LB timeout |
| `"message larger than max"` | Proto message 超过 4MB 限制 | 调大 `MaxCallRecvMsgSize` |
| `PROTOCOL_ERROR` / `INTERNAL` | 中间代理篡改了 HTTP/2 frame | 检查 Nginx / Envoy 配置，确保启用 http2 |
| 某个 stream 卡住但不报错 | Server 端 handler 阻塞或未回写 | 用 `GRPC_TRACE=stream,transport` 定位 |
| DNS 解析慢导致首次调用超时 | gRPC 内置 resolver 异步解析但首次调用不等 | 提前预热连接或用固定 IP |

## 附录：gRPC 协议分层速览

```mermaid
block-beta
    columns 1
    block:App
        columns 1
        A1["Protobuf Message<br/>(序列化后的 byte[])"]
    end
    space
    block:GRPC
        columns 1
        B1["gRPC Frame<br/>(Wire type + Length + Payload)"]
    end
    space
    block:HTTP2
        columns 1
        C1["DATA Frame"]
        C2["HEADERS Frame"]
        C3["WINDOW_UPDATE Frame"]
    end
    space
    block:Transport
        columns 1
        D1["HTTP/2 Stream<br/>(multiplexed over one TCP)"]
    end
    space
    D2["TCP Socket"]

    A1 --> B1
    B1 --> C1
    B1 --> C2
    B1 --> C3
    C1 --> D1
    C2 --> D1
    C3 --> D1
    D1 --> D2

    style A1 fill:#FFD43B
    style B1 fill:#00B6BC,color:#fff
    style D1 fill:#4FC08D,color:#fff
```

## 关联笔记

- [[../1. Protobuf 基础篇/01-Protobuf 语法与消息定义]]
- [[../3. 服务端实现/08-Server 搭建与注册]]
- [[../3. 服务端实现/09-Streaming Handler]]
- [[../4. 客户端开发/11-Client 连接与 Dial]]
- [[../4. 客户端开发/12-Call Options 与 Context]]
- [[../6. 工程实践篇/20-性能优化与压测]]