Go crypto/tls ClientSessionCache 如何观察会话复用

线上客户端把连接数扩容后，TLS 握手耗时仍然偶尔升高，最容易误判的地方是：HTTP 连接复用、ClientSessionCache 命中和服务端真正接受会话恢复，并不是同一个信号。可执行的观察方案是给缓存包一层并发安全的计数器，再把它和每条新连接的 ConnectionState.DidResume 对照。

先看缓存的 Get/Put 判断“有没有可用票据”，再看 DidResume 判断“这次 TLS 握手是否真的恢复成功”。如果 HTTP Transport 直接复用了已有 TCP 连接，就没有新的 TLS 握手，也不能用它证明会话恢复。

• 观察入口：复用同一个 tls.Config.ClientSessionCache，记录 Get 命中、Put 更新和删除。
• 最终证据：新连接完成握手后读取 ConnectionState.DidResume，不要只看缓存命中。
• 上线边界：缓存容量、并发安全、Keep-Alive、TLS 版本和服务端策略都可能改变结果。

先把复用观察点放在缓存边界上

ClientSessionCache 是客户端保存 ClientSessionState 的接口，标准库提供了 NewLRUClientSessionCache。它只负责让客户端在下一次新 TLS 连接建立时找到候选会话，并不承诺服务端一定接受恢复。

因此第一层指标应放在缓存边界：Get 返回命中，说明本地找到了与会话键对应的状态；Put 表示服务端提供了可保存的会话票据。TLS 1.3 可能在一条连接中提供多个票据，Put 不应被当成“一条连接只发生一次”的计数。

用并发安全包装器记录 Get 与 Put

标准接口明确要求实现能够应对不同 goroutine 的并发调用。在线上不要直接改标准库 LRU 的内部状态，而是包一层，只保存计数和少量脱敏后的键摘要；票据本身不应写入日志。

package main

import (
    "crypto/tls"
    "crypto/sha256"
    "encoding/hex"
    "log"
    "sync"
    "sync/atomic"
)

// observingCache 只增加观察能力，真正的会话状态仍交给标准库 LRU 保存。
type observingCache struct {
    mu       sync.Mutex
    base     tls.ClientSessionCache
    gets     atomic.Uint64
    hits     atomic.Uint64
    puts     atomic.Uint64
    removes  atomic.Uint64
}

func (c *observingCache) Get(key string) (*tls.ClientSessionState, bool) {
    // 用原子计数避免高并发 Get 把统计本身变成竞争源。
    c.gets.Add(1)
    c.mu.Lock()
    session, ok := c.base.Get(key)
    c.mu.Unlock()
    if ok {
        c.hits.Add(1)
    }
    log.Printf("tls cache get key=%s hit=%t", shortKey(key), ok)
    return session, ok
}

func (c *observingCache) Put(key string, session *tls.ClientSessionState) {
    // nil 表示移除；不能把它误记成一次成功缓存。
    c.mu.Lock()
    c.base.Put(key, session)
    c.mu.Unlock()
    if session == nil {
        c.removes.Add(1)
    } else {
        c.puts.Add(1)
    }
}

func shortKey(key string) string {
    // 只记录稳定摘要，避免日志暴露完整会话键。
    sum := sha256.Sum256([]byte(key))
    return hex.EncodeToString(sum[:4])
}

func main() {
    cache := &observingCache{
        base: tls.NewLRUClientSessionCache(128), // 容量按目标主机数量和内存预算调整。
    }
    _ = cache
}

这个包装器只回答“缓存层发生了什么”。统计输出建议按服务主机、TLS 版本和连接来源聚合，并把键做摘要；如果只在单机实验中使用，也要保留锁，因为 Transport 的多个请求可能同时触发握手。

把 DidResume 作为最终证据

要观察真正的恢复结果，必须让客户端建立一条新 TLS 连接。HTTP Keep-Alive 命中时，后续请求沿用原来的连接，不会再次执行 TLS 握手；这时缓存统计没有新一轮含义。测试代码可以临时关闭 Keep-Alive 或主动关闭空闲连接，生产环境则应把连接复用状态单独记账。

transport := &http.Transport{
    // 仅为观察新连接的握手；生产环境不要靠关闭 Keep-Alive 提升性能。
    DisableKeepAlives: true,
    TLSClientConfig: &tls.Config{
        RootCAs:            roots,
        ClientSessionCache: cache,
    },
}
client := &http.Client{Transport: transport}

resp, err := client.Get(target)
if err != nil {
    return err
}
defer resp.Body.Close() // 及时关闭响应体，避免把连接层问题误判成缓存问题。

if resp.TLS == nil {
    return errors.New("response has no TLS state")
}
state := resp.TLS
log.Printf("tls version=%s resumed=%t", tlsVersionName(state.Version), state.DidResume)
// DidResume=true 才表示本次新握手接受了会话恢复。

一个可复查的结果表应至少保留四列：是否新建连接、Get 是否命中、服务端是否写入票据、DidResume 是否为 true。第一条新连接通常先得到缓存未命中；后续新连接即使 Get 命中，也可能因票据过期、服务端策略、协议限制或证书/配置变化而恢复失败。

在容量、并发和失效边界上收敛指标

容量不是越大越好。标准 LRU 的容量过小会频繁驱逐，导致 Get 命中率下降；容量过大则会让多主机客户端持有更多状态。先按目标主机数量、连接创建速率和进程内存预算估算，再观察驱逐后的命中变化。

上线时建议把四类信号分开：same connection 表示 HTTP/TCP 连接复用，cache hit 表示本地找到状态，Put 表示缓存被更新，DidResume=true 才表示服务端接受了这次 TLS 会话恢复。这样才能判断瓶颈是在连接池、客户端缓存，还是在服务端票据策略。

常见问题

为什么缓存命中但 DidResume 仍然是 false？因为命中只是客户端找到了候选状态，最终还要经过服务端票据、协议版本、时间有效性和配置条件的判断。把 Get 命中率和 DidResume 比值同时监控，才能看出“有票据但没被接受”的变化。

ClientSessionCache 应该每次请求都新建吗？不应该。要让不同新连接共享会话状态，应把同一个缓存挂在复用的 tls.Config 上；每次创建新缓存都会把之前积累的状态丢掉，观察到的低命中率也就失去了参考价值。