Go tls.ClientSessionCache 命中率低时先看哪些条件

Go 里把 tls.Config.ClientSessionCache 换成更大的 LRU，并不等于 TLS 恢复率一定会上升。先看一个容易被忽略的事实：ClientSessionCache 只参与新的 TLS 连接，http.Transport 如果一直复用已有连接，根本不会产生新的缓存查询。真正出现低命中时，优先检查缓存是否启用、同一服务是否使用同一个缓存键，以及缓存条目是否还满足版本、证书和票据条件。

先确认确实发生了新的 TLS 握手

如果业务使用一个长期存活的 http.Transport，请求大多走连接池，看到的只是连接复用，不是 ClientSessionCache 的命中率。只有连接被关闭、连接池建立新连接，或代码主动创建新的 tls.Conn 时，客户端才会尝试从缓存取会话。

因此排查时至少分开记录三件事：创建了多少条新的 TLS 连接、缓存 Get 返回了多少条、最终有多少条连接的 ConnectionState().DidResume 为 true。只看第二个数字，容易把“没有新握手”误判为缓存失效。

核对 ClientSessionCache、票据开关和缓存键

Go 客户端在 ClientSessionCache 为 nil，或 SessionTicketsDisabled 为 true 时，不会尝试会话恢复。默认的 tls.NewLRUClientSessionCache 可以先用于基线测试；自定义实现还必须能承受并发调用，并正确处理 Put(key, nil) 这一删除语义。

缓存键是另一个高频原因。当前实现优先使用 tls.Config.ServerName，没有服务名时才退回到底层连接的远端地址。多个入口域名、IP 地址与域名混用、每次请求动态生成不同的 ServerName，都会把同一后端拆成多个键。先在测试环境固定一个服务名，再观察 Get 参数是否稳定。

检查缓存条目是否被 Go 的恢复条件淘汰

Get 返回条目只说明“缓存里找到了对象”，不代表服务端最终接受恢复。Go 还会检查上一次会话版本是否仍在本次 ClientHello 的支持范围内；TLS 1.2 要求原密码套件仍可用，TLS 1.3 要求至少有匹配的哈希套件。证书过期、主机名校验失败、验证链不再有效、TLS 1.3 票据过期，也会放弃恢复并可能删除缓存条目。

服务端也要参与判断：它需要提供并接受对应的 session ticket。客户端本地缓存命中、但服务端重启后不再接受旧票据时，最终仍可能是完整握手。多实例服务还要确认票据密钥和终止 TLS 的配置符合部署方式，不能只盯着客户端 LRU。

用 DidResume 做一次最小验证

下面的包装器只负责计数，不改变标准库缓存逻辑。测试时用同一个 tls.Config 和同一个缓存，连续建立几条独立连接；每条连接都读取 ConnectionState().DidResume，这样才能知道恢复是否真的发生。

type meterCache struct {
    inner tls.ClientSessionCache
    gets  atomic.Uint64
    hits  atomic.Uint64
}

func (m *meterCache) Get(key string) (*tls.ClientSessionState, bool) {
    // Get 统计缓存查询；命中仍要由最终 DidResume 结果确认。
    m.gets.Add(1)
    state, ok := m.inner.Get(key)
    if ok && state != nil {
        m.hits.Add(1)
    }
    return state, ok
}

func (m *meterCache) Put(key string, state *tls.ClientSessionState) {
    // nil 代表标准库要求删除这个缓存键，不能忽略。
    m.inner.Put(key, state)
}

func main() {
    cache := &meterCache{inner: tls.NewLRUClientSessionCache(64)}
    config := &tls.Config{
        // 固定 ServerName，让多次连接使用同一个缓存键。
        ServerName:         "api.example.com",
        ClientSessionCache: cache,
    }
    for i := 0; i 

如果 cache_hit 上升但 did_resume 仍然全是 false，优先回到证书、票据有效期、协议版本和服务端接受条件；如果连 cache_hit 都很低，先查 ServerName、缓存容量和是否真的建立了新连接。生产环境不建议为了命中率关闭证书校验，InsecureSkipVerify 只适合受控测试并需要额外验证。

相关问题

为什么把 LRU 容量调大后仍然没有改善？

如果问题是没有新 TLS 握手、缓存键不一致或服务端拒绝旧票据，容量变化不会改变结果；先分别观察 Get 和 DidResume。

ClientSessionCache 可以跨进程共享吗？

标准接口本身是进程内回调式缓存。想跨进程持久化需要自定义序列化方案，并正确处理敏感的会话状态，不能直接把内存对象当作通用缓存值。

TLS 1.3 为什么可能多次调用 Put？

官方接口说明允许服务端发送多个 session ticket，因此一次连接可能多次写入；自定义缓存不要假设一次连接只有一条票据。