Automatic Key Exchange 面向边缘节点与客户源站之间的 TLS 1.3 连接：系统主动探测源站支持的密钥协商算法，记录能力，并在后续连接中优先发送更安全的选项；只要源站支持，就优先建立后量子安全连接。来源标题提到的日均 450 亿次连接，说明这不是一次实验室里的算法替换，而是一项需要兼顾握手延迟、兼容性和持续演进的大规模工程。
它自动选择的究竟是什么
TLS 1.3 客户端会在握手中声明支持的密码组，并携带一个或多个密钥份额（key share）。如果源站接受客户端已经发送的密钥份额，双方可以直接继续握手；如果源站支持 TLS 1.3，却需要另一个协商组，就可能返回 HelloRetryRequest，让客户端重新发送合适的密钥份额。
因此，边缘代理面对的不是简单的“源站是否支持 TLS 1.3”，而是更细粒度的问题：
- 这个源站支持哪些密钥协商组？
- 哪个选项符合当前安全策略？
- 能否直接发送源站会接受的 key share，避免额外往返？
- 源站升级、回滚或者切换节点后，旧的探测结果是否仍然有效？
Automatic Key Exchange 的关键动作可以概括为：
探测源站能力 -> 记录可用算法 -> 按安全策略排序 -> 首次发送最优 key share
这里的“自动”很重要。若只能通过人工配置维护每个源站的算法列表，在数以万计的源站、不同 TLS 实现和滚动发布面前，配置很快就会过期。
为什么能力探测既影响安全，也影响速度
后量子安全并不意味着可以忽略网络往返。对跨区域的边缘到源站连接来说，多一次握手往返就可能放大建连尾延迟。预先了解源站能力，可以让客户端一开始就带上更合适的密钥份额，从而降低触发重试或降级路径的概率。
安全收益则来自选择顺序。与其长期使用兼容性最广但安全策略较旧的算法，系统可以在确认源站支持后，把后量子算法放到优先位置。实际部署中通常还要考虑混合密钥交换：将传统算法与后量子算法组合，避免把所有安全性押在单一的新算法或实现上。具体算法名称和组合方式应以双方 TLS 库实际支持的能力为准，不能把某个草案名称直接写死在全局配置中。
能力学习也不能等同于永久缓存。生产实现至少需要处理：
- 多个源站 IP 的 TLS 能力可能不同；
- 同一主机名背后可能运行不同版本的软件；
- 探测结果需要过期时间，并在失败后重新验证；
- 探测连接必须校验证书、SNI 和主机名，不能只看握手是否完成；
- 新算法失败时需要受控回退，同时记录失败原因，避免无限重试。
在本地复现“探测后选择”
下面的脚本使用 OpenSSL 启动一个只支持 TLS 1.3、且仅开放 X25519 和 prime256v1 的本地源站，然后分别测试三个协商组。运行前确认系统已安装支持 TLS 1.3 的 OpenSSL。
#!/usr/bin/env bash
set -euo pipefail
WORKDIR="$(mktemp -d)"
trap 'kill "${SERVER_PID:-0}" 2>/dev/null || true; rm -rf "$WORKDIR"' EXIT
openssl req -x509 -newkey rsa:2048 -nodes \
-keyout "$WORKDIR/key.pem" \
-out "$WORKDIR/cert.pem" \
-days 1 \
-subj "/CN=localhost" >/dev/null 2>&1
openssl s_server \
-accept 8443 \
-cert "$WORKDIR/cert.pem" \
-key "$WORKDIR/key.pem" \
-tls1_3 \
-groups X25519:prime256v1 \
-www >"$WORKDIR/server.log" 2>&1 &
SERVER_PID=$!
sleep 1
for group in X25519 prime256v1 secp521r1; do
echo "=== probing $group ==="
if openssl s_client \
-connect 127.0.0.1:8443 \
-servername localhost \
-tls1_3 \
-groups "$group" \
-brief </dev/null 2>&1; then
echo "supported: $group"
else
echo "not negotiated: $group"
fi
echo
done
预期结果是前两个协商组能够完成握手，而 secp521r1 因为不在服务端允许列表中而失败。这个实验没有实现完整的 Automatic Key Exchange，但展示了其最小闭环：主动提供候选组、观察协商结果，再把成功结果用于后续连接。
若要测试后量子或混合协商组，客户端和服务端必须同时使用支持该组的 TLS 实现。不同版本暴露的名称可能不同，可以先检查本机能力：
openssl version
openssl list -tls-groups 2>/dev/null | grep -Ei 'MLKEM|KYBER' || true
在确认双方支持后，再把实际组名代入：
PQ_GROUP="X25519MLKEM768" # 按本机 TLS 实现显示的名称修改
openssl s_client \
-connect origin.example.com:443 \
-servername origin.example.com \
-tls1_3 \
-groups "$PQ_GROUP" \
-verify_hostname origin.example.com \
-verify_return_error </dev/null
这里的 X25519MLKEM768 只是常见的混合组示例，不代表所有 OpenSSL 版本或源站都支持它。生产探测还应使用可信 CA 路径，并区分“不支持该组”“证书错误”“网络超时”和“源站限流”等失败类型。
落地时不要把探测器变成故障放大器
大规模能力探测最好采用异步、限速和带抖动的调度方式。若所有缓存同时过期，探测流量可能在短时间内冲击源站；若把临时网络故障误判为算法不兼容，又可能导致整个流量面错误降级。
可以按下面的清单评估实现：
- 缓存维度：至少考虑主机名、端口、SNI 和源站地址，而不是只按域名保存结果。
- 结果有效期：成功与失败使用不同 TTL，临时失败不应长期污染能力记录。
- 安全排序：由集中策略定义优先级，不依赖各节点自行猜测。
- 回退边界：明确允许回退到哪些算法，禁止为了连通性退到不符合基线的配置。
- 可观测性：记录选中的组、HelloRetryRequest、握手耗时、回退次数和证书错误。
- 渐进发布：先在少量源站或连接上启用，再观察失败率与尾延迟。
Automatic Key Exchange 的价值不只是“支持某个后量子算法”，而是把 TLS 能力发现、算法选择和兼容性回退变成持续运行的控制环。后量子能力会随 TLS 库、源站版本和标准演进而变化；让连接端根据真实能力自动选择，才有机会在不牺牲稳定性的前提下，把更安全的握手推向数百亿级连接。