Go 1.24 原生 h2c 服务端：无需 TLS 的 HTTP/2 多路复用

HTTP/2 的多路复用与头部压缩能显著降低延迟，但传统实现依赖 TLS 握手，这在某些场景下反而成为阻碍。Go 1.24 在 net/http 标准库中原生引入了对 HTTP/2 Cleartext（h2c）的支持，允许开发者在不启用 TLS 的情况下直接使用 HTTP/2 的全部特性。这一变化不仅简化了代码结构，更为内网服务网格、Sidecar 通信等场景提供了更高效的传输方案。

从 x/net/http2/h2c 到标准库原生支持

在 Go 1.24 之前，开发者若想在明文连接上使用 HTTP/2，必须引入 golang.org/x/net/http2/h2c 包。这个方案虽然可行，但存在明显的痛点：需要额外管理依赖、与 net/http 的交互逻辑较为复杂、且行为边界不够清晰。更糟糕的是，客户端若要通过明文使用 HTTP/2，往往需要在 http2.Transport 中设置 AllowHTTP 并提供自定义的 DialTLS 函数来返回非加密连接 —— 这种 "假装 TLS" 的做法既不优雅，也容易引发维护问题。

Go 1.24 的解决方案是将 h2c 支持直接整合进标准库。核心改动是引入了新的 http.Protocol 常量 UnencryptedHTTP2，让 HTTP/2 成为与 HTTP/1.x 平起平坐的一等公民。

启用 h2c 的核心机制

Go 1.24 为 http.Server 和 http.Transport 新增了 Protocols 字段，用于显式声明支持的协议版本。启用 h2c 服务端只需在创建 Server 时配置该字段：

srv := &http.Server{
    Addr: ":8080",
    Handler: handler,
    Protocols: []http.Protocol{http.HTTP1, http.UnencryptedHTTP2},
}

当 Server.Protocols 包含 UnencryptedHTTP2 时，服务器会在明文端口上接受 HTTP/2 连接。更关键的是，Go 1.24 支持 HTTP/1.x 与 HTTP/2 在同一端口共存 —— 服务器会根据客户端的协议协商自动选择合适的处理方式，无需开发者手动分流。

值得注意的是，Go 1.24 仅支持 "prior knowledge" 方式启动 HTTP/2，即客户端在建立连接时就知晓对方支持 HTTP/2，直接发送 HTTP/2 帧。RFC 7540 定义的 Upgrade: h2c 机制已被 RFC 9113 废弃，Go 团队也明确表示不会支持这种复杂的协议升级流程 —— 它要求在中途转换连接协议，且初始 HTTP/1 请求体必须完整发送后才能开始传输 HTTP/2 帧，实际使用价值有限。

客户端配置与协议协商

对于客户端而言，若要通过明文使用 HTTP/2，同样需要配置 Transport.Protocols：

transport := &http.Transport{
    Protocols: []http.Protocol{http.UnencryptedHTTP2},
}
client := &http.Client{Transport: transport}

当 Transport.Protocols 仅包含 UnencryptedHTTP2 而不包含 HTTP1 时，传输层会对 http:// URL 直接使用 HTTP/2 "prior knowledge" 连接。这种设计让客户端和服务端都能精确控制协议行为，避免了旧方案中 AllowHTTP 开关的模糊语义。

典型应用场景

h2c 最适用的场景是已经存在 TLS 终止点的内网环境。当流量从边缘负载均衡器进入后，内部服务之间的通信往往不再需要逐跳加密 —— 此时 h2c 可以在保证传输效率的同时避免重复的 TLS 握手开销。

具体场景包括：

服务网格内部通信：Istio、Linkerd 等服务网格的 Sidecar 代理通常负责 TLS 终止，后端服务使用 h2c 可以获得 HTTP/2 的多路复用能力，同时避免 mTLS 的证书管理复杂度。

Sidecar 模式：主容器与辅助容器（如日志收集、监控代理）之间的本地通信，使用 h2c 可以在 Unix Domain Socket 或本地 TCP 上获得流控和优先级调度能力。

内部 API 网关：当网关层已完成认证和加密，下游微服务使用 h2c 可以降低 CPU 占用，特别是在高并发短连接场景下，HTTP/2 的连接复用优势更加明显。

安全边界与注意事项

尽管 h2c 带来了便利，但必须明确其安全边界。明文传输意味着流量可被网络中的任何节点嗅探和篡改，因此 h2c 仅适用于已隔离的可信网络环境 —— 如 Kubernetes Pod 网络、VPC 内部子网、或已通过 WireGuard/IPsec 等底层方案加密的网络。

在生产环境中启用 h2c 时，建议采取以下措施：

• 网络隔离：通过防火墙规则限制 h2c 端口的访问来源，确保只有受信任的服务可以连接
• 协议白名单：在 Server 的 Protocols 字段中显式声明允许的协议版本，避免意外降级到不安全的 HTTP/1.0
• 监控埋点：记录连接使用的协议版本（r.Proto），便于审计和异常检测
• 超时配置：HTTP/2 的长连接特性需要合理设置 IdleTimeout 和 ReadTimeout，防止僵尸连接占用资源

与旧方案的对比

对于新项目，建议直接使用 Go 1.24 的原生方案；对于已有使用 h2c 包的项目，迁移成本较低 —— 只需移除 h2c 包装器，改为配置 Server.Protocols 即可。

总结

Go 1.24 对 h2c 的原生支持是 x/net/http2 迁移到标准库计划的重要一环。通过 UnencryptedHTTP2 协议标识，开发者可以在内网环境中便捷地启用 HTTP/2 的多路复用与流控能力，而无需承担 TLS 的开销。这一特性特别适合服务网格、Sidecar 通信等场景，但在使用时必须严格限定在可信网络边界内，并配合适当的监控与隔离措施。

参考来源

• Go Issue #67816: net/http: support unencrypted HTTP/2 (h2c) — Go 官方提案与实现细节
• posener.github.io/http2/ — HTTP/2 in Go 的技术背景与演进历程

systems