Go net/http 怎样给自定义连接提供 TLS ALPN 状态

Go 1.27 中，自定义连接只要实现 ConnectionState() tls.ConnectionState，net/http 就能读取它的 TLS ALPN 状态。最稳妥的做法是把调用转发给实际承载字节流的 TLS 连接，而不是自己拼一个声称协商了 h2 的结构体。客户端的 DialTLSContext 还必须返回已经完成握手的连接。

官方地址：https://go.dev/

我关注的是接口扩展，不是重写 TLS

阅读 Go 1.27 的 net/http 变更时，我更关心连接包装器能否保留协商信息：为了统计读写字节或接入已有网络设施，业务可能不直接向标准库交付 *tls.Conn。现在标准库允许通过同签名的方法获得状态，Transport 和 Server 都在此次支持范围内。官方说明见 Go 1.27 net/http 发布说明。

这是接口兼容性的扩展，不是自动加密、自动补握手或一定升级 HTTP/2 的承诺。我倾向先保留默认网络栈；只有确实需要自定义连接时，才承担额外的配置责任。以下代码是原创集成示例，没有在本任务编译或联网运行，也不包含实际性能结论。

只嵌入 net.Conn，可能把 TLS 方法藏起来

最容易忽略的是 Go 的方法集。假设包装器只嵌入 net.Conn，内部动态对象虽然是 *tls.Conn，外层类型却只自动暴露 net.Conn 接口声明的方法；ConnectionState 不在其中。包装器可以正常读写，并不代表 net/http 能从外层取得协商状态。

我会给这种包装器明确增加 ConnectionState 方法。若直接嵌入 *tls.Conn，方法可以提升到外层，但需要留意是否又被后续包装隐藏。关键检查对象是最终交给标准库的动态类型，而不只是最里面的 TLS 类型。

谁值得采用，哪些责任不会消失

这对已有连接包装层的客户端库、网络观测组件和自定义监听器更有意义。普通 HTTPS 客户端直接使用标准 Transport 即可，不必专门增加一层包装。对我来说，减少对具体连接类型的依赖是收益，但维护者仍得对协议和会话的一致性负责。

特别是设置 DialTLSContext 后，直连 HTTPS 不再走 Transport 的 DialContext；TLSClientConfig 和 TLSHandshakeTimeout 也不会替自定义拨号器承担握手工作。不能只改 Transport.TLSClientConfig，却让自己的 TLS 拨号器使用另一份配置。

我会先让握手成功，再返回透明包装

下面示例只演示无代理的直连 HTTPS。它用 tls.Dialer 完成真实握手，保留证书校验，显式声明 HTTP/1 与 HTTP/2；握手失败便返回错误，不交付半成品连接。连接建立与握手共享五秒的局部超时，整个请求再受 Client.Timeout 约束。

package alpnclient

import (
    "context"
    "crypto/tls"
    "net"
    "net/http"
    "time"
)

// 字节流和状态提供者必须来自同一个 TLS 连接。
type wrappedTLS struct {
    net.Conn
    session *tls.Conn
}

func (c *wrappedTLS) ConnectionState() tls.ConnectionState {
    // 返回真实状态，不构造伪造的 h2 协商结果。
    return c.session.ConnectionState()
}

// 编译期接口约束仅表达本例设计，不代表运行结果。
var _ interface {
    net.Conn
    ConnectionState() tls.ConnectionState
} = (*wrappedTLS)(nil)

func NewClient() *http.Client {
    cfg := &tls.Config{
        MinVersion: tls.VersionTLS12,
        NextProtos: []string{"h2", "http/1.1"},
    }
    dialer := &tls.Dialer{Config: cfg}
    tr := http.DefaultTransport.(*http.Transport).Clone()
    // 本例明确不走环境代理，不直接用于必须经过代理的网络。
    tr.Proxy = nil
    protocols := new(http.Protocols)
    protocols.SetHTTP1(true)
    protocols.SetHTTP2(true)
    tr.Protocols = protocols
    tr.DialTLSContext = func(ctx context.Context, network, addr string) (net.Conn, error) {
        handshakeCtx, cancel := context.WithTimeout(ctx, 5*time.Second)
        defer cancel()
        conn, err := dialer.DialContext(handshakeCtx, network, addr)
        if err != nil {
            return nil, err
        }
        // tls.Dialer 成功返回的连接为 *tls.Conn，握手已经完成。
        session := conn.(*tls.Conn)
        return &wrappedTLS{Conn: session, session: session}, nil
    }
    // 客户端应在多次请求间复用，不要每次请求都重建连接池。
    return &http.Client{Transport: tr, Timeout: 15 * time.Second}
}

这里没有给 ServerName 写死一个域名：tls.Dialer 在配置未指定名称时，会根据拨号地址处理名称。若生产环境通过自定义路由把业务域名映射到另一个地址，必须重新设计 SNI、主机名验证与目标地址的关系，不能简单复制本例后关闭校验。自定义 CA 也应配置在拨号器真正使用的 cfg 上。

我不在构造器里加入“协商不是 h2 就报错”，因为允许 HTTP/1.1 回退本来就是本例的选择。只接受 HTTP/2 是另一种产品策略，需要与协议列表、远端能力和失败处理一起明确约定。

把 ALPN 结果与实际 HTTP 协议分别观察

ConnectionState 中的 HandshakeComplete 表示握手是否完成，NegotiatedProtocol 是 ALPN 选中的应用协议。NextProtos 是候选列表，不能当成结果；NegotiatedProtocol 为空，也不能直接判定连接未加密。实际 HTTP 响应还应看 resp.Proto，不能把 URL 是 https 当成使用了 HTTP/2。

如果要在读者自己的环境确认集成，可以在已有请求代码中引入 fmt，成功取得响应后按以下方式记录必要字段，使用完仍要关闭响应体。日志不要扩大到完整证书、会话票据或其他无关身份信息。

// 放在 client.Do(req) 成功之后；resp 由现有请求代码取得。
defer resp.Body.Close()
fmt.Printf("HTTP协议=%s\n", resp.Proto)
if resp.TLS != nil {
    // 只记录握手和应用协议，不转储完整 TLS 状态。
    fmt.Printf("握手完成=%t ALPN=%q\n",
        resp.TLS.HandshakeComplete, resp.TLS.NegotiatedProtocol)
}

我的采用顺序是先处理客户端直连路径，再分别评估代理和服务端监听器。Server.Serve 对监听器返回连接也支持相同方法，但服务端还有证书配置、监听器返回对象及协议处理器等约束，不能把这里的客户端构造器改个名字就当成服务器代码。连接包装方法并不会为明文 Listener 自动增加 TLS。

返回固定的 NegotiatedProtocol: "h2" 可以吗？

不可以。它没有完成 ALPN，也无法改变线上字节协议，可能导致上层按错误协议解释数据。必须转发实际会话的状态。

实现这个方法就一定会用 HTTP/2 吗？

不会。协议支持、握手协商和 HTTP 栈配置都要一致。对端不支持、列表不匹配或路径不同，结果都会变化。

旧 Go 版本可以直接依赖这个识别方式吗？

本文针对 Go 1.27 的扩展约定。即使包装器的方法可以编译，也不能据此推断旧版 net/http 已具备相同识别行为；需要按目标版本官方文档决定兼容策略。

对我而言，这项变化适合修复“连接可用，状态却被包装丢失”的接口问题，不是为了少几行代码重写 TLS 的理由。官方参考：Transport 拨号契约、Serve 的连接要求、TLS 拨号器、ConnectionState 字段。