Go TLS 会话恢复为什么不能保证复用同一条连接

结论先说：TLS 会话恢复只能复用先前握手产生的会话状态，不能把已经关闭、失效或不在连接池里的 TCP 连接重新变成同一条连接。它发生在一条新连接的 TLS 握手阶段；而 HTTP 连接复用是 http.Transport 从连接池里拿到一条仍可用的现有连接，两者不在同一层。

判断时不要只问“有没有复用”。先问复用的是 TCP 连接，还是 TLS 会话状态；再分别看 GotConnInfo.Reused 与 ConnectionState.DidResume。

先把两个复用概念拆开

http.Transport 负责连接池。请求结束后，满足条件的连接会进入空闲池；后续请求命中它时，Reused 为真。这条路径直接沿用旧 TCP 连接，因此不会再触发 TLS 握手。

tls.Config.ClientSessionCache 管的是另一件事：当客户端不得不新建 TCP 连接时，TLS 可以尝试带上之前保存的会话状态。服务器接受后，当前连接的 DidResume 为真；服务器拒绝、缓存未命中或状态失效时，就回到完整握手。无论结果如何，这仍是一条新 TCP 连接。

调用方真正需要的是少建连接还是少做完整握手

如果目标是降低延迟和端口消耗，优先让连接保持可复用：长期共享一个 http.Client 与它的 Transport，读完并关闭响应体，设置合理的空闲连接上限。只要旧连接还能用，就没有必要讨论会话恢复。

如果业务存在负载均衡切换、空闲超时、网络抖动或服务端主动关连接，新 TCP 连接不可避免，这时会话恢复才可能减少完整握手的成本。它是连接池失效后的第二道优化，不是连接池的替代品，也不是“永远命中”的承诺。

客户端参数设计：共享 Transport 与 ClientSessionCache

客户端配置的关键是把两种状态都放在长生命周期对象上：Transport 保存连接池，ClientSessionCache 保存可用于恢复的客户端会话状态。每次请求都重新创建它们，会同时丢掉两类收益。

sessionCache := tls.NewLRUClientSessionCache(128)

transport := &http.Transport{
    TLSClientConfig: &tls.Config{
        // 启用客户端会话缓存；nil 表示不尝试会话恢复。
        ClientSessionCache: sessionCache,
        MinVersion:         tls.VersionTLS12,
    },
    // 连接池参数按目标主机数量和并发量调整。
    MaxIdleConns:        100,
    MaxIdleConnsPerHost: 10,
    IdleConnTimeout:     90 * time.Second,
}

// 整个进程共享 client，不要为每次请求重新创建。
client := &http.Client{
    Transport: transport,
    Timeout:   15 * time.Second,
}

ClientSessionCache 为 nil 时，客户端会话恢复被关闭。容量也不是越大越好，应根据目标主机数量、并发与内存预算设置。服务器端是否接受恢复仍由服务器配置、票据状态和协议协商共同决定。

分别观测 Reused 和 DidResume

httptrace.ClientTrace 可以在一次请求内同时观察连接获取与 TLS 握手。GotConn 的 Reused 回答“拿到的是不是已有连接”；TLSHandshakeDone 里的 DidResume 回答“本次新握手是否恢复了旧会话”。

需要注意：如果请求直接复用了旧连接，就不会产生新的 TLS 握手，因而本次请求通常不会触发 TLSHandshakeDone。不能因为没有收到该回调，就把 DidResume 当成假。

为什么明明配置缓存仍可能完整握手

会话缓存只提供“尝试恢复”的材料，不构成成功保证。以下情况都可能让新连接执行完整握手：

• 客户端缓存尚无可用状态，或者对应条目已被 LRU 淘汰。
• 服务器拒绝恢复，票据已经过期，或服务端密钥轮换后旧票据不再可用。
• 目标主机、SNI、TLS 版本、应用协议或安全配置发生变化，原状态不适用于当前连接。
• 请求实际落到不同服务实例，而实例之间没有可兼容的恢复配置。
• 首次连接尚未获得后续可用的恢复状态，立即重试时仍可能完整握手。

TLS 1.2 与 TLS 1.3 的恢复机制和握手细节不同，因此不要把“恢复成功”写成固定节省某个 RTT 的保证。更可靠的做法是记录实际指标，并以目标部署环境中的延迟分布为准。

错误处理与兼容边界

HTTP 层常见误判来自响应体处理。对于需要继续复用连接的请求，应消费并关闭响应体；如果提前丢弃未读响应体，Transport 可能无法把连接安全放回空闲池。

resp, err := client.Do(req)
if err != nil {
    return fmt.Errorf("发送请求失败: %w", err)
}
defer resp.Body.Close()

// 小响应可读完后丢弃，帮助 Transport 判断连接可继续复用。
if _, err := io.Copy(io.Discard, resp.Body); err != nil {
    return fmt.Errorf("读取响应失败: %w", err)
}

服务端发送 Connection: close、空闲超时、连接出错或协议侧主动收敛连接时，即使客户端配置了连接池，也可能新建连接。HTTP/2 还会在一条连接上并发承载多个请求，这仍属于连接复用，与 TLS 会话恢复是两回事。

不要为了提高恢复命中率设置 InsecureSkipVerify。会话恢复不会取消证书和主机身份的安全边界，降低验证强度既不能保证复用，也会引入中间人攻击风险。

最小观察示例

下面的追踪代码把两种信号分别打印。连续请求时，第二次请求可能直接复用连接；如果连接被关闭后又建立新连接，则可能看到 Reused=false 与 DidResume=true 同时出现。

trace := &httptrace.ClientTrace{
    GotConn: func(info httptrace.GotConnInfo) {
        // Reused 只说明是否拿到了已有连接。
        log.Printf("connection_reused=%t was_idle=%t", info.Reused, info.WasIdle)
    },
    TLSHandshakeDone: func(state tls.ConnectionState, err error) {
        if err != nil {
            log.Printf("tls_handshake_error=%v", err)
            return
        }
        // DidResume 只描述当前 TLS 握手是否恢复了旧会话。
        log.Printf("tls_did_resume=%t tls_version=0x%x", state.DidResume, state.Version)
    },
}

req, err := http.NewRequest(http.MethodGet, "https://api.example.com/health", nil)
if err != nil {
    log.Fatal(err)
}
req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))

resp, err := client.Do(req)
if err != nil {
    log.Fatal(err)
}
defer resp.Body.Close()
_, _ = io.Copy(io.Discard, resp.Body)

排障时应把主机名、协议、Reused、WasIdle、握手错误和 DidResume 关联到同一次请求。仅看总耗时，无法分辨是 DNS、TCP 建连、完整 TLS 握手、恢复握手还是服务端处理造成的变化。

常见问题

Reused=true，但没有看到 DidResume=true，正常吗？

正常。连接已经被复用时没有新 TLS 握手，本次请求可能根本不触发 TLSHandshakeDone。这通常比新建连接后再恢复会话更省。

Reused=false 与 DidResume=true 能同时出现吗？

可以。这正是“新 TCP 连接上恢复旧 TLS 会话”的典型组合，说明没有复用旧连接，但握手复用了会话状态。

每次都创建新的 http.Client 会怎样？

如果同时创建新的 Transport，连接池无法跨请求复用；如果会话缓存也重新创建，TLS 恢复状态同样无法积累。应共享配置完成的 Client，除非确实需要隔离代理、证书或安全策略。

如何判断优化应该放在哪一层？

先统计 Reused。连接复用率低时，优先检查响应体、空闲超时和 Transport 生命周期；确认新连接不可避免后，再统计新握手中的 DidResume，检查缓存与服务端恢复配置。

结语

Go 中的连接复用与 TLS 会话恢复是互补机制：前者尽量不建新连接，后者在必须建新连接时尽量避免完整握手。用共享 http.Transport 保住连接池，用共享 ClientSessionCache 提供恢复机会，再用 Reused 和 DidResume 分层观测，才能避免把“恢复会话”误解成“复用同一条连接”。