Go HTTP/2HTTP/2 头部压缩错误如何分类

Go 服务遇到 HTTP/2 头部压缩错误时，先别把它当成普通的业务参数错误。HTTP/2 的头部块由 HPACK 解码器还原，索引、动态表、Huffman 字符串和头部大小任何一处不一致，都可能让连接直接被关闭。真正有效的处理方式，是先确认错误发生在帧组装还是 HPACK 解码，再根据错误类型决定是修客户端、代理，还是收紧服务端的头部预算。

从现象判断是协议层还是业务层

我处理这类故障时，第一眼看的是连接级日志，而不是接口返回的 JSON。若请求还没有进入 Handler 就出现连接复位、GOAWAY 或 PROTOCOL_ERROR，同时日志里出现 header block、HPACK 或 decoding 字样，问题通常在协议层。此时重试业务请求不会改变结果，因为同一个客户端或中间代理会再次发送相同的压缩状态。

HTTP/2 的 HEADERS 帧可能和 CONTINUATION 帧共同组成一个 header block。帧被截断、顺序被打乱，和 block 已经完整但 HPACK 内容非法，是两类不同故障。前者优先查代理、连接复用和帧转发；后者再进入索引、字符串和动态表分析。

沿着 HPACK 四类证据定位根因

可以把日志和抓到的错误按下面四组归类。分类的价值在于它直接决定下一步找谁，而不是为了给错误贴标签。

HPACK 的静态表和动态表共享索引空间，但请求和响应方向的动态表彼此独立。把一个方向的压缩字节流拿到另一个方向复用，或者在代理重连后继续沿用旧上下文，都会把看似正常的索引变成非法索引。RFC 7541 还明确要求，超出表范围的索引和不符合 Huffman 规则的填充都应视为解码错误。

Go 中如何保留足够的错误上下文

不要只把底层错误格式化成一条字符串。能拿到 golang.org/x/net/http2/hpack 解码器错误时，至少保留错误类型、请求或响应方向、远端地址、连接标识和当前 header block 的来源。下面的分类函数只负责把错误映射到排查分支，真实服务还应把分类结果和连接日志关联起来。

package main

import (
    "errors"
    "fmt"

    "golang.org/x/net/http2/hpack"
)

func classifyHPACK(err error) string {
    // 先判断规范定义的解码错误，再区分长度限制，避免只依赖错误文本。
    var decoding hpack.DecodingError
    var invalidIndex hpack.InvalidIndexError
    switch {
    case errors.As(err, &invalidIndex):
        return "invalid-index"
    case errors.As(err, &decoding):
        return "hpack-decoding"
    case errors.Is(err, hpack.ErrStringLength):
        return "string-length"
    default:
        return "transport-or-frame"
    }
}

func logClassification(err error, remote string) {
    // 远端和分类一起记录，便于判断是否只集中在某个代理或客户端。
    fmt.Printf("http2 header error class=%s remote=%s err=%v\\n",
        classifyHPACK(err), remote, err)
}

示例里的 transport-or-frame 不是“没有问题”，而是提示你把调查范围退回 HEADERS/CONTINUATION 的完整性、连接复用和中间层。若服务只使用标准库 net/http，可以保留同样的分类思想，但不要假设所有内部 HTTP/2 类型都能直接从公开 API 断言。

修复动作按边界落地

索引类错误，先固定复现请求并隔离最近增加的 HTTP/2 代理或连接池改动；不要通过随机清空服务端动态表来掩盖状态不同步。Huffman 或变长整数错误，优先升级或回退产生 header block 的客户端和代理，并确认没有把多个连接的字节流拼在一起。

如果线索是长度超限，统计 Cookie、Authorization、分布式追踪和自定义头的总量，给它们设置明确预算。把超长会话状态移到服务端存储通常比无限抬高限制稳妥。动态表更新错误则要核对 SETTINGS 协商时机，确保更新只作用于同一条连接上的正确方向。

修复验证要使用同一类头部组合：一个普通请求、一个包含大 Cookie 的请求、一个经过代理复用连接的请求。每次只改变一个变量，并观察 GOAWAY、解码错误分类和 Handler 是否真正收到请求。

让错误分类成为防复发检查

生产上建议至少保留四个维度：错误分类、对端地址或客户端标识、HTTP/2 连接标识、头部总量区间。日志中的敏感头值要脱敏，只记录名称、长度和哈希。这样既能判断是单一代理实现问题，也能发现某类 Cookie 增长把系统推过边界。

不要把“临时关闭 HTTP/2”当作最终修复。降级后错误可能消失，但它只改变了编码路径。保留一组脱敏后的回归请求，在升级 Go、代理或 SDK 后重新走 HTTP/2；如果错误再次出现，就能很快知道是帧组装、HPACK 状态还是头部预算发生变化。

常见问题

看到 compression error 就一定是压缩算法实现错了吗？

不一定。帧截断、动态表状态不同步、非法索引和头部过大都可能在同一层表现为压缩相关错误，先看错误类型和帧边界。

把动态表大小调大能解决所有头部压缩错误吗？

不能。它只可能缓解预算不足，无法修复非法索引、Huffman 编码错误或 CONTINUATION 顺序问题。

为什么换成 HTTP/1.1 后请求就正常了？

HTTP/1.1 不经过 HPACK，所以绕开了故障路径。这说明排查方向正确，但还需要修复产生或转发 HTTP/2 header block 的组件。