Go TLS 会话恢复开启后为什么仍会完整握手

Go 里“已经开启 TLS 会话恢复”并不等于下一条连接一定恢复成功。客户端必须配置并复用同一个 ClientSessionCache，首次连接还要真正收到并处理会话票据；随后缓存键、票据有效期、TLS 版本、证书状态和服务端票据密钥都要兼容。最终不要凭握手耗时猜测，直接读取 ConnectionState.DidResume。

官方文档：https://pkg.go.dev/crypto/tls

现象：第二条连接仍然是 DidResume=false

我第一次遇到这个问题时，客户端已经设置了会话缓存，服务端也没有关闭票据，但第二条 TCP 连接的 DidResume 仍然是 false。业务请求能成功，表面上只是“握手多走了一遍”，真正的影响却是每次新连接都重复证书链验证和密钥协商，连接密集时会增加 CPU 与建立连接的等待时间。

先把判断口径固定下来。连接复用、握手变快、抓包里消息变少都可能被误读，Go 已经给出直接证据：

state := conn.ConnectionState() // 握手完成后读取连接状态
if state.DidResume {
    log.Printf("TLS 会话恢复成功，版本=%#x", state.Version) // 记录明确的恢复结果
} else {
    log.Printf("本次执行完整握手，版本=%#x", state.Version) // 不用耗时推测结果
}

如果使用 net/http，还要先确认第二次请求是否真的建立了新 TCP/TLS 连接。复用同一条 keep-alive 或 HTTP/2 连接时根本没有第二次握手，自然谈不上“恢复成功还是失败”。

排查时间线：缓存到底有没有命中

我后来把排查顺序改成“先看缓存，再看服务端”。客户端必须满足两个最基础条件：SessionTicketsDisabled 不能为 true，ClientSessionCache 不能为 nil。更容易忽略的是，两次连接要共享同一个缓存实例；如果每次拨号都新建 tls.NewLRUClientSessionCache，第二次连接看到的仍是空缓存。

cache := tls.NewLRUClientSessionCache(64) // 在多次连接之间复用同一个缓存

cfg := &tls.Config{
    ServerName:         "service.example.com", // 稳定主机名也参与缓存键选择
    ClientSessionCache: cache,                 // nil 会关闭客户端会话恢复
    MinVersion:         tls.VersionTLS12,       // 允许当前安全默认范围内的协议版本
}

conn, err := tls.Dial("tcp", "service.example.com:443", cfg) // 新建真实 TLS 连接
if err != nil {
    return err // 连接失败时保留原始错误链
}
defer conn.Close() // 结束后释放底层连接

log.Printf("did_resume=%t", conn.ConnectionState().DidResume) // 用字段确认结果

Go 的客户端缓存键优先使用 Config.ServerName；没有设置时才退回远端地址字符串。两次连接如果一个使用主机名、另一个使用 IP，或 ServerName 在不同租户配置中发生变化，就可能查到不同键。缓存容量太小导致票据被 LRU 淘汰，也会表现为完整握手。

第一个根因：TLS 1.3 票据还没写入缓存

TLS 1.2 的票据与握手关系较直观，但 TLS 1.3 的 NewSessionTicket 是握手完成后的消息。Go 客户端收到该消息后，才会构造 ClientSessionState 并调用缓存的 Put。如果测试程序只调用 Handshake，随即关闭连接，客户端可能尚未读取到票据，第二条连接当然只能完整握手。

在 HTTP 场景里，完整读取并关闭响应体通常会让连接继续处理服务端发来的记录。下面的示例让两次请求共享同一缓存，并主动关闭空闲连接来迫使第二次请求新建 TCP/TLS 连接：

cache := tls.NewLRUClientSessionCache(64) // 两次请求共享票据缓存
transport := &http.Transport{
    TLSClientConfig: &tls.Config{
        ClientSessionCache: cache, // 客户端缓存不能按请求重建
        MinVersion:         tls.VersionTLS12,
    },
}
client := &http.Client{Transport: transport}

for attempt := 1; attempt 

这段代码的目的不是制造固定输出，而是把“缓存复用”和“连接复用”拆开。真实服务是否发送可用票据，仍由服务端配置、协议协商和票据策略决定。

第二个根因：缓存键或服务端密钥不一致

当缓存中已经出现票据，下一步就要检查身份一致性。Go 会依据 ServerName 或远端地址查找会话；随后还会判断旧会话版本是否仍被当前 ClientHello 支持、证书是否过期、主机名是否仍能验证、验证链是否仍有效。TLS 1.2 还要求原密码套件继续被提供；TLS 1.3 则要求至少提供一个 KDF 哈希兼容的套件。任一条件不满足，客户端都会放弃旧会话并走完整握手。

多实例服务端是另一类高频触发点。第一次连接由节点 A 签发票据，第二次被负载均衡到节点 B；如果 B 没有对应的票据密钥，就无法恢复。Go 服务端默认会自动轮换票据密钥，但需要跨终止同一主机连接的服务器同步时，应按官方接口管理 SetSessionTicketKeys。如果使用自定义 UnwrapSession，返回 (nil, nil) 代表忽略本次会话，crypto/tls 也仍可能基于安全条件拒绝恢复。

用缓存包装器确认 Get 和 Put

排障时可以给标准 LRU 缓存包一层轻量日志，只记录缓存键和命中状态，不打印票据内容。这样能快速区分“首次连接从未 Put”“第二次连接使用了另一个 key”和“命中后又被删除”。

type tracingCache struct {
    inner tls.ClientSessionCache // 复用并发安全的底层缓存实现
}

func (c *tracingCache) Get(key string) (*tls.ClientSessionState, bool) {
    session, ok := c.inner.Get(key) // 先执行真实查询
    log.Printf("tls cache get key=%q hit=%t", key, ok) // 不输出敏感票据内容
    return session, ok
}

func (c *tracingCache) Put(key string, session *tls.ClientSessionState) {
    log.Printf("tls cache put key=%q remove=%t", key, session == nil) // nil 表示删除条目
    c.inner.Put(key, session) // 委托给标准缓存保存或删除
}

这个包装器只适合短期诊断。生产环境如果主机名也属于敏感信息，应做脱敏或仅记录稳定哈希；高并发场景还要控制日志量。

修复动作与防复发清单

我现在会同时记录“新建 TLS 连接数”“缓存 Get/Put 命中情况”和 DidResume，而不是只看请求耗时。这样服务端轮换、负载均衡调整或客户端配置重建后，会话恢复率变化能很快定位到具体层次。

相关问题

ClientSessionCache 配了就一定会恢复吗？

不会。它只提供客户端存取会话状态的能力，服务端仍可不发票据、拒绝票据或因为兼容条件变化执行完整握手。

为什么第一次请求必须读取响应体？

在 TLS 1.3 中，会话票据属于后握手消息。连接继续读取记录时，Go 才有机会处理票据并调用缓存 Put；只完成 Handshake 就立即关闭，可能错过它。

HTTP/2 第二次请求很快，算会话恢复吗？

不一定。它更可能只是复用了现有 HTTP/2 连接，没有创建新的 TLS 会话。只有新连接的 DidResume 为 true 才能证明恢复成功。

服务端自动票据密钥为什么多实例仍失败？

自动管理通常只覆盖各自配置实例。负载均衡把后续连接分配到另一台服务器时，如果该服务器无法解开原票据，就会回退到完整握手；需要明确设计跨实例恢复域。