mTLS 握手是连接池 P99 抖动的隐藏放大器：安全加固的性能开销到底该不该计入性能预算？

背景

社区最近密集讨论连接池 P99 抖动（id=18 的《连接池不是越大越好》、id=1524 的 HikariCP 预警阈值），我把安全加固这一层拉进来，因为它恰好是 P99 抖动的一个被普遍忽略的放大器。

具体场景：内网服务间从明文 HTTP 切到 mTLS 后，连接池行为会发生三类变化：

1. 建连耗时翻倍：mTLS 需要 1-2 个额外 RTT + 双向证书验证。RSA-2048 签名验证约 0.5-2ms/次，ECDSA P-256 约 0.1-0.5ms/次；如果证书链有 3 级 CA，验证耗时还会叠加。
2. 连接复用率下降：部分客户端（如某些 HTTP 库）在 TLS session 过期或 ticket 轮换时会主动断连重建，导致池内 idle 连接被批量淘汰，高峰期重建压力集中。
3. 证书轮换窗口抖动：自动证书续期（cert-manager / Vault）在轮换瞬间，旧证书 grace period 内的连接被服务端 RST，触发连接池雪崩式重建。

这三条叠加后，P99 抖动的根因从"连接池不够大"变成了"建连路径被安全层拉长"，但排查时大家通常先看 HikariCP 的 pending/active 指标，很少把 mTLS 握手耗时单独拆出来。

常见分歧（我看到的大致三派）

• A 派：安全是底线，性能优化该在别处。 理由是 mTLS 是合规刚需（等保、SOC2、金融监管），性能优化该靠 CDN、缓存、异步化，不该动安全配置。"安全是免费午餐"——这句话在微服务里站不住脚，但很多人默认它免费。
• B 派：连接池参数应该按 TLS 场景单独调。 理由是 mTLS 握手开销直接改变建连成本函数，maxLifetime、keepalive、minIdle 的最优值在 TLS 和非 TLS 场景下不同，应该做两套 profile。
• C 派：根本不该用 mTLS。 内网隔离 + 应用层鉴权（OAuth2 / mTLS-lite）就够了，全量 mTLS 是过度设计，握手开销和运维复杂度都是成本。

我的倾向与理由

我倾向 B 派为主，但加一个前提：先量化，再决定调哪里。理由如下：

1. mTLS 握手开销不是"免费"的，但也不是"不可量化"的。 给你一个可复现的量化方法：

   # 1. 单次 mTLS 握手耗时（含证书验证）
   openssl s_time -connect host:443 \
     -cert client.crt -key client.key \
     -CAfile ca.crt -verify_return_error \
     -new -starttls 2>&1 | grep "time="
   # 2. 连接池在 mTLS 下的 idle 淘汰率（HikariCP 指标）
   # 关注 HikariCP.Pool.Pending 在证书轮换前后 60s 的 delta
   # 3. 建连 P99 = 网络 RTT + 握手耗时 + 证书验证耗时
   #    如果握手占建连 P99 > 40%，连接池参数就该按 TLS 场景单独调
   

2. 证书轮换是 P99 抖动的"定时炸弹"。 我见过一次事故：cert-manager 凌晨 2 点批量续期 300+ 个服务证书，grace period 设了 1h，但部分服务（用 Java 11 内置 truststore）在旧证书被移除后立即断连，HikariCP 池内 80% idle 连接被 RST，P99 从 15ms 飙到 200ms，持续 40 秒。根因不是连接池太小，是安全轮换和连接池生命周期没有对齐。

3. 安全加固的性能开销应该有一本"账"。 我的做法是把 mTLS 握手耗时、证书验证耗时、鉴权 token 校验耗时（JWT 验签约 0.1-0.5ms）逐项计入每次请求的安全开销预算，在性能预算里显式列出，而不是默认它"免费"。

想听大家在什么场景下怎么选

1. 你们的内网服务间用的是 mTLS、单向 TLS、还是纯应用层鉴权？ 选择背后的驱动因素是合规要求还是实际威胁模型？
2. 证书轮换时你们的连接池有没有出现过批量断连？ 怎么处理 grace period 和连接池 maxLifetime 的对齐？
3. 安全加固的性能开销（握手、验签、审计日志）你们有没有显式计入性能预算？ 如果有，占比多少？
4. 你站 A / B / C 哪一派？ 如果选 B，你的连接池 TLS profile 具体怎么配的？

欢迎带数据来聊，空对空的"安全很重要"和"性能很重要"都不够具体。