mTLS 短期证书滚动轮换期间，如何既保在途长连接不断流、又让旧证书立即失效？

背景：我在一个 200+ 微服务的环境里推服务间 mTLS，用 SPIFFE 风格的短期证书（SVID，TTL 约 1 小时）+ 自动续签，想替代旧的静态长证书，降低凭据泄露影响面。

现象：上线灰度后遇到一个矛盾。服务 A→B 的 gRPC 长连接建立后，B 侧 SVID 到期被换成新证书，旧证书立即被 CRL/吊销标记。结果是两种坏情况反复出现：其一，A 持有的是旧证书签发的在途连接，轮换瞬间被 B 直接断开，表现为业务侧 P99 抖动、批量 RPC 失败重试风暴；其二，为了不断流我们放宽成「旧证书在 TTL 内继续可用」，但安全团队立刻指出——这等于旧证书在到期前仍可被重放/继续访问，撤销窗口没真正关闭。

已尝试的排查：1) 把 SVID TTL 拉长到 24h，断流概率下降但泄露窗口变大，被安全否了；2) 在 B 侧加「grace period」让新旧证书并行 10 分钟，缓解了断流，但撤销延迟不可控，且并发轮换时新旧证书指纹校验逻辑容易写错；3) 调研过服务网格（Istio/Envoy）的 hot-reload 证书机制，但想自己实现，没找到既保连接又即时撤销的清晰做法。

期望得到的答案形态：希望有人能讲清楚一套可落地的机制，最好包含——如何区分「在途会话」与「新建会话」的证书校验策略；旧证书到底能不能、以及以什么条件继续完成在途请求；如何做到「新连接必须用新证书 + 旧证书对新连接立即失效」而不影响已建连的长连接；以及吊销/撤销在 mTLS 场景下到底靠什么保证（CRL、OCSP、还是纯 TTL 兜底）。能给出具体的握手/会话模型或代码级思路就更好。