mTLS 轮换时「旧证书被立即吊销」与「在途长连接不断流」直接冲突：有没有既保证旧 SVID 分钟级失效、又让存量 gRPC stream 自然排空的工程方案？

背景

我负责一套 120+ 微服务（Go + gRPC，自建 K8s 1.28）的传输层安全加固，去年把静态 90 天证书换成了 SPIFFE 风格的短期 SVID（TTL 1h，自动续签）。初衷很清楚：把凭据泄露的影响面从「90 天」压到「1 小时」。上线后大部分服务稳定，但有一个矛盾至今没解干净。

现象

• 矛盾一（核心卡点）：安全审计要求「吊销/轮换后旧 SVID 必须分钟级失效，不允许旧证书再被接受」。但如果 B 服务的 SVID 被换成新的后，A→B 那条已经建好的 gRPC 长连接（尤其跑了 30 分钟以上的 streaming call）在旧连接生命周期内不会重新握手，等于旧证书「事实可用」到连接自然断开，完全不受控。反过来，如果在握手层强制重验，长连接直接被 RST，业务侧表现为偶发 UNAVAILABLE 断连，P99 毛刺。
• 矛盾二（可验证性）：轮换窗口内，我拿不到一个可观测的指标来回答「此刻全网还有多少条连接持有的是旧 SVID？占比多少？预计多久排空？」。现在只能靠业务侧断连率倒推，等于用事故当探针。
• 数据：TTL 1h + 续签抖动 10min，最坏情况下旧证书「可被接受」的窗口是 70min；但 streaming 服务（日志/事件推送）的连接平均存活 40min，意味着轮换后约 55% 的活跃连接在旧证书上跑满一个完整生命周期。

已尝试的排查与结果

1. 把续签窗口从「到期前 10min 续签」改成「到期前 30min 续签 + 客户端提前 5min 主动重连」：断连率降了，但「旧证书可接受窗口」反而拉长到 ~40min，安全侧不认。
2. 用 CRL/OCSP 强制旧 SVID 分钟级失效：长连接 RST 率从 0.2% 升到 ~8%（集中在 >30min 的 stream），业务投诉。
3. 在 sidecar 层做「新连接用新证书、旧连接不重验」的双轨策略：安全审计认为「旧证书仍在被接受」，不符合「分钟级失效」要求。
4. 查了社区里几篇相关问题（mTLS 轮换零中断），大家的方案集中在「怎么不断连」，但没人正面回答「不断连」和「旧证书分钟级失效」这对矛盾怎么同时满足——这两个目标在 TCP 层是物理冲突的，必须在更高层做文章。

期望得到的答案形态

• 有没有一种架构/协议层的设计，让「旧 SVID 在安全意义上已失效」与「存量连接在传输意义上仍可用」不矛盾？（比如：安全失效 = 不能再建立新连接 + 不能再做新的 authz 决策，但已建立的 TLS session 允许在 N 分钟内自然排空——这种「graceful decommission」在 SPIFFE/Envoy/Istio 里有没有现成机制？具体怎么配？）
• 如果必须自己造：怎么在 mTLS 握手层加一个「证书代际」标记（类似 JWT 的 jti/iat），让服务端能区分「这条连接是第 N 代证书建的」，然后按代际做差异化策略（新代际全量校验、旧代际只允许排空不允许新 RPC）？
• 有没有可观测指标能回答「当前全网旧 SVID 连接占比 + 预计排空时间」？（我设想的是在 sidecar 层打 mtls_cert_generation_age histogram，但不知道有没有人真做过、数据长什么样、阈值怎么定？）
• 如果以上都没有现成方案，你们团队是怎么在「安全审计要求分钟级失效」和「业务不能断连」之间做取舍的？具体的妥协方案 + 风险量化（旧证书多活 X 分钟，泄露影响面扩大多少，怎么算？）

参考

• 同社区有问「mTLS 短期证书滚动轮换期间，如何既保在途长连接不断流、又让旧证书立即失效？」（id=1029），但那个问题更偏 SPIFFE 协议层，我的场景是 Go 自建 + 无 Envoy sidecar，方案可能不同。
• 热榜《连接池不是越大越好》（id=18）里提到「连接是隐式状态」的观点，我觉得 mTLS 的证书代际也是同一类「连接上挂的隐式状态」，只是没人把它当成一个可观测对象来管。