Cloudflareは、オリジン接続における「HelloRetryRequests」（TLS 1.3ハンドシェイクのステップの一つで、レイテンシを追加する可能性があるもの）の発生頻度を52%からわずか3.7%に削減しました。この変化は、Automatic Key Exchange (AKE)によって推進されています。AKEは、オリジンサーバーの暗号化能力をプロアクティブに特定することで、初期接続時における「推測と再試行」のサイクルを排除するシステムです。

ステートレスハンドシェイクの問題

標準的なTLS 1.3ハンドシェイクでは、クライアントとサーバーは鍵交換アルゴリズムについて合意する必要があります。プロトコルをステートレスに保つために、クライアントはサポートされているアルゴリズムについて最初の「推測」を行うことがよくあります。

最初の推測が正しくない場合、サーバーは「HelloRetryRequest」を発行し、クライアントに再試行を強制します。これにより、接続に余分なラウンドトリップのレイテンシが追加され、高トラフィックのサービスにおいてパフォーマンスに影響を与える可能性があります。

Automatic Key Exchangeの仕組み

CloudflareのAKEは、オリジンサーバーを毎日プロアクティブにスキャンすることでこの問題に対処します。それは一連の軽量なハンドシェイクを実行し、それぞれが正確に一つの鍵合意グループを提示することで、オリジンが処理できるものを確認します。

これらのスキャンの結果は保存され、Cloudflareのプロキシネットワーク全体に配布されます。ユーザーが接続する際、プロキシはすでに優先される鍵交換グループを知っているため、最初のリクエストで正しいパラメータを送信することができます。

議論と技術的なトレードオフ

Hacker Newsのコメントでは、この最適化のトレードオフについて議論されました。ラウンドトリップのレイテンシを節約できる一方で、プロキシに配布する必要のある少量のステート（状態）が導入されることが指摘されました。sandeepkdというハンドル名のコメント投稿者は、記事がこのステートを取得するためにすべての接続に追加される「絶対的なルックアップレイテンシ」を開示していないことを指摘しました。

別のコメント投稿者であるLoganDarkは、このような最適化が、同様の高度な最適化を実装するためのリソースを欠いている可能性のある独立したサーバー運営者と、大規模なインフラプロバイダーとの間の拡大する格差を浮き彫りにしていると観察しました。

運用の考慮事項

スキャンプロセスは、オリジンのパフォーマンスに影響を与えないよう、意図的に本番トラフィックのパス外に保たれています。しかし、一部のユーザーは、異なる構成を持つ複数のオリジンによってバックアップされているホスト名の正確な優先順位をCloudflareがどのように維持しているかについて疑問を呈しました。

また、プロキシのステートに関する理論的なリスクもあります。edelbitterというハンドル名のコメント投稿者は、プロキシに送信される構成データの量を増やすことで、異常な動作のトラブルシューティングがより困難になったり、プロキシソフトウェアのハードリミットを超えたりする可能性があると推測しました。