在 TLS 1.3 连接中，客户端和服务端对密钥交换组的偏好不一致时，服务端可能发送 HelloRetryRequest，要求客户端重新发起一次握手。这个额外往返会直接增加延迟。Cloudflare 最近将面向源站的静态 X25519 猜测改为按源站测量，使扫描到的源站中触发 HelloRetryRequest 的比例从约 52% 降至 3.7%，p90 延迟减少了 150 毫秒以上。
更值得注意的是，这套测量也改善了后量子 TLS 连接：能够在一次往返内完成连接的比例从 0% 提升到 99.2%。不过，当前仅有 12.8% 的源站支持后量子连接，因此测量优化和协议能力仍然是两个不同问题。
静态猜测为什么会失效
客户端通常会在 ClientHello 中携带自己支持的密钥交换组。服务端根据自身配置选择一个组；如果客户端没有提供服务端优先选择的组，TLS 1.3 就需要通过 HelloRetryRequest 让客户端补充合适的参数。
问题在于，使用全局固定策略时，Cloudflare 必须为大量不同配置的源站选择同一个默认答案。X25519 是一个合理的常见选择，但“常见”不等于“适合每个源站”。源站的 TLS 库、操作系统、硬件加速、后量子配置和部署历史都可能不同。
这类优化的关键不是增加一次更聪明的重试，而是把握手结果当作运行时信号：
- 记录某个源站实际接受或偏好的密钥交换组。
- 将测量结果用于后续发往该源站的连接。
- 在配置变化或测量失效时重新验证，而不是永久依赖旧结论。
结果：少一次往返，延迟就少一截
扫描结果显示，HelloRetryRequest 比例从约 52% 降到了 3.7%。这意味着绝大多数原本需要重新协商的连接可以在首轮握手中继续完成。对于跨地域访问的源站，减少一次往返通常比微调 CPU 或加密算法实现更容易体现在用户可见的 p90 延迟上。
按源测量还有一个工程上的好处：它把复杂性放在连接管理层，而不要求所有源站立即升级。代理或边缘网络可以逐步积累观测结果，再对每个源站采用更合适的握手偏好。
但测量缓存也会带来边界条件。源站可能切换负载均衡集群、升级 TLS 库或修改安全策略，因此缓存结果必须有失效和回退机制。错误的历史测量不应让连接持续失败，最稳妥的行为通常是退回通用策略并重新观测。
后量子 TLS：一次往返已经可行，但支持率仍有限
Cloudflare 的数据还显示，后量子连接在一次往返内完成的比例从 0% 提升至 99.2%。这说明当源站已经支持相应的后量子密钥交换组合时，按源测量能够显著降低协商失败或重试的概率。
不过，只有 12.8% 的源站支持后量子连接。这个数字提醒我们区分两个指标：
- 在“支持后量子”的源站中，连接是否高效完成。
- 所有源站中，有多少真正具备后量子能力。
前者已经取得明显改善，后者仍需要源站升级 TLS 软件、配置和基础设施。边缘网络不能仅靠策略测量替代源站能力建设。
如何在自己的环境中观察握手行为
下面的命令适合用于验证一个测试域名的 TLS 版本、密钥交换组和握手过程。请将 example.com 替换为自己拥有或获准测试的域名。不同 OpenSSL 版本的输出字段可能略有差异，因此应把它作为诊断工具，而不是稳定的机器解析接口。
HOST=example.com
# 查看 TLS 1.3 握手中协商出的密钥交换信息
openssl s_client \
-connect "${HOST}:443" \
-servername "${HOST}" \
-tls1_3 \
-brief </dev/null 2>&1
# 观察完整握手消息；搜索 HelloRetryRequest、supported_groups 等字段
openssl s_client \
-connect "${HOST}:443" \
-servername "${HOST}" \
-tls1_3 \
-msg </dev/null 2>&1 | \
grep -E 'HelloRetryRequest|supported_groups|key_share|ServerHello'
如果要做持续观测，可以让探针定期记录以下维度，而不是只保存“成功或失败”：
origin, timestamp, tls_version, offered_groups, selected_group,
hello_retry_request, handshake_duration_ms, protocol_error
在生产环境中，建议将这些数据按源站聚合，并设置结果有效期。例如，连续多次观测到同一组成功协商后再提高其优先级；一旦出现协议错误、握手延迟异常或源站配置变更信号，就清除缓存并回到默认候选组。不要为了消除重试而关闭证书校验、降低 TLS 版本或强行启用未经验证的算法。
采用这类优化前的检查清单
- 确认客户端发送的
supported_groups和key_share与服务端 TLS 库的实际能力。 - 单独统计
HelloRetryRequest比例、握手耗时和连接失败率。 - 为按源测量结果设置 TTL、版本标记和异常回退。
- 将后量子支持率与后量子连接的一次往返完成率分开看。
- 在真实跨地域链路上比较 p50、p90 和 p99，而不要只看本地基准。
- 保留通用默认策略，避免某个过期测量结果影响整个源站集群。
Cloudflare 这次变化的核心启示并不是“永远选择某个特定密钥交换组”，而是：当协议协商依赖对端能力时，运行时测量往往比全局静态猜测更可靠。测量、缓存、失效和回退共同构成了可运营的 TLS 优化方案。