Cloudflare 已将其源站连接中的“HelloRetryRequests”频率（这是 TLS 1.3 握手中的一个可能增加延迟的步骤）从 52% 降低到仅 3.7%。这一转变是由自动密钥交换 (AKE) 驱动的，该系统主动识别源站服务器的加密能力，从而消除在初始连接期间所需的“猜测并重试”循环。
无状态握手的问题
在标准的 TLS 1.3 握手中，客户端和服务器必须就密钥交换算法达成一致。为了保持协议的无状态特性，客户端通常会对支持的算法进行初步的“猜测”。
如果第一次猜测不正确，服务器将发出“HelloRetryRequest”，迫使客户端重新尝试。这为连接增加了额外的往返延迟，可能会影响高流量服务的性能。
自动密钥交换的工作原理
Cloudflare 的 AKE 通过每天主动扫描源站服务器来解决此问题。它执行一系列轻量级握手，每次提供恰好一个密钥协商组，以确认源站可以处理的内容。
这些扫描结果被存储并分发到 Cloudflare 的代理网络中。当用户连接时，代理已经知道首选的密钥交换组，使其能够在第一次请求中发送正确的参数。
讨论与技术权衡
Hacker News 上的评论者讨论了这一优化的权衡，指出虽然它节省了往返延迟，但引入了少量必须分发到代理的状态。一位以 sandeepkd 为名的评论者指出，文章并未披露为了检索此状态而在每个连接中增加的“绝对查找延迟”。
另一位以 LoganDark 为名的评论者观察到，此类优化突显了大规模基础设施提供商与独立服务器运营商之间日益扩大的差距，后者可能缺乏实施类似高规模优化的资源。
运营考量
扫描过程有意保持在生产流量路径之外，以避免影响源站的性能。然而，一些用户提出了关于 Cloudflare 如何为由具有不同配置的多个源站支持的主机名维护准确首选项的问题。
关于代理状态也存在理论风险；一位以 edelbitter 为名的评论者推测，增加发送到代理的配置数据量可能会使故障排除异常行为变得更加困难，或者可能超过代理软件中的硬性限制。