解读

国内金融、运营商、政务云对“零信任”合规要求趋严，mTLS 几乎成为 Istio 生产落地的必选项。5 ms 的 RT 增量在 2C 场景可能尚可接受，但在 1000 QPS 的支付、秒杀链路中，5 ms 会直接放大到 5 s 的尾延迟，导致 SLA 击穿。面试官真正想考察的是：

1. 能否把“5 ms”拆成可量化、可复现的指标；
2. 能否在 Istio 数据面（Envoy）里找到加密、握手、会话复用三条消耗路径；
3. 能否给出“改配置→压测→回滚”的闭环方案，而不是只背参数。

知识点

1. Istio mTLS 数据面链路：
   • 业务 Pod → iptables → Envoy Sidecar (outbound) → 网络 → Envoy Sidecar (inbound) → 业务 Pod
   • 每条链路都要做一次 TLS 握手，RT 增量 = 2×(ECC 握手 + 证书校验 + OCSP) + 2×Envoy 加解密 filter 耗时
2. Envoy 支持的 TLS 版本与算法：
   • TLS 1.2 默认使用 ECDHE-RSA-AES256-GCM-SHA384，TLS 1.3 默认 TLS_AES_256_GCM_SHA384
   • 国密场景下可切换至 ECC-SM2-SM4-SM3，但 SM 套件在 Envoy 1.24+ 才 GA，且需要 BoringSSL 补丁
3. 会话复用机制：
   • Session ID（有状态，Sidecar 重启失效）
   • Session Ticket（无状态，需同步 ticket key 到所有 Sidecar）
   • PSK（TLS 1.3 0-RTT，需打开 istiod 的 PILOT_ENABLE_TLS_3 特性门）
4. 国内可落地的压测基线：
   • 使用阿里云 PTS 或腾讯 WeTest 在“北京-上海”双 AZ 专线环境，100 并发、1 KB 报文、keep-alive 长连接，基线 RT 不含 mTLS 为 8 ms
   • 目标：mTLS 场景下 RT ≤ 10 ms（增幅 ≤ 2 ms），P99 增幅 ≤ 4 ms
5. 灰度与回滚：
   • 通过 Istio EnvoyFilter 按 Header（env=canary）灰度 5% 流量，验证后再全量
   • 回滚策略：直接删除 EnvoyFilter，Sidecar 热重启 50 ms 内完成，无需重建 Pod

答案

回答时分三步：量化、定位、优化。

第一步：量化

1. 在压测脚本里把“握手阶段”与“应用阶段”拆列：
   • 用 wrk2 -L 输出每个请求的 time_to_first_byte（TTFB）
   • 用 tcpdump 在客户端 Sidecar 抓包，标记 ClientHello → ServerHelloDone 的 RTT 作为“握手耗时”
2. 对比开启 mTLS 前后，确认 5 ms 增量里 3.8 ms 来自握手，1.2 ms 来自对称加解密

第二步：定位

1. 查看 Envoy 的 listener filter_chain 配置，确认 cipher_suites 列表排在第一的是 ECDHE-RSA-AES256-GCM-SHA384，该算法在 2 vCPU 的容器里单核加解密延迟约 0.8 ms/1 KB
2. 查看 istiod 的日志，发现 PILOT_ENABLE_TLS_3 未开启，TLS 1.3 0-RTT 无法使用；同时 session_ticket_keys 未注入，导致全握手比例 98%

第三步：优化

1. 算法层面：
   • 通过 EnvoyFilter 把 cipher_suites 调整为 ["TLS_AES_128_GCM_SHA256", "TLS_CHACHA20_POLY1305_SHA256"]，AES-128 比 AES-256 在 x86_64 上快 25%，ChaCha20 在手机端 ARM 无 AES-NI 场景下快 30%
   • 若合规允许，关闭 RSA 证书，改用 ECC P-256，握手计算量下降 60%
2. 会话复用：
   • 在 istiod 的 configmap 里打开 PILOT_ENABLE_TLS_3=true，全局启用 TLS 1.3
   • 创建 Secret 存储 80 字节的 session_ticket_keys，按 24h 轮转；同时把 max_session_keys 提高到 10 万，保证 30 min 内复用率 ≥ 90%
   • 对移动端长连接业务，在 VirtualService 里加入 keepalive: interval: 30s，减少短连接触发全握手
3. 压测验证：
   • 重复第一步的脚本，优化后握手耗时降至 0.9 ms，对称加解密降至 0.4 ms，整体 RT 增量从 5 ms 降到 1.3 ms，P99 增幅 2.1 ms，满足 SLA
4. 灰度上线：
   • 先对订单服务的 v2 版本灰度 5% 流量，监控“业务成功率、RT、CPU” 三项指标 30 min 无异常后全量；回滚策略保留旧 EnvoyFilter 的 revision，确保 1 min 内可回滚

拓展思考

1. 如果业务需要国密合规，但 SM 套件导致 CPU 暴涨 30%，如何权衡？
   思路：在入口网关层做 SM 卸载，内部 Sidecar 仍用 TLS 1.3+AES-128，把合规边界限定在南北向，东西向保持高性能
2. 当集群规模达到 5k Pod，Session Ticket Key 的同步延迟导致复用率下降，如何解决？
   思路：把 key 的分发从 K8s Secret 改为基于 Istio CA 的 SDS 推送，利用现有的证书轮换通道，延迟从 30 s 降到 2 s
3. 若未来 Istio 推出 HBONE（HTTP-Based Overlay Network Environment）隧道，加密开销会再次上升，如何提前评估？
   思路：在 Istio 1.20 alpha 阶段就用 Fortio 打标基线，把“HBONE+TLS”与“纯TLS”做双轨压测，提前输出容量模型，避免上线后被动回滚