CloudflareのAKEが脅威の改善！HelloRetryRequestを52%から3.7%まで大幅削減

Cloudflareが実装したAuthenticated Key Exchange（AKE）により、TLSハンドシェイク時に発生するHelloRetryRequestの割合を、52%からわずか3.7%にまで劇的に減らすことに成功しました。これにより、オリジンサーバーの負荷が軽減され、接続のレイテンシが大幅に改善される見込みです。

素朴な疑問なんだけど、なんでこれまでこれをやってこなかったんだろう？クリティカルパス上の明白で手っ取り早い改善に思えるから、自分の想像以上に何か複雑な事情があるんだろうね。

要約すると：

1. TLSハンドシェイクでは共通してサポートされているアルゴリズムを確認するステップがある。最初の推測が外れると往復回数が増えてしまうことがあって、これはステートレス性を保つためのプロトコル仕様の一部。

2. Cloudflareは全オリジンを毎日スキャンしてサポートされているアルゴリズムの結果を保存しておくことで、この往復時間を節約しようとしている。

記事で触れられていない点：

• 節約できるのは「発生する可能性のある往復のレイテンシ」であって、今回新しく追加されたルックアップ（参照）のレイテンシが各接続にどれだけ加わるのかという絶対的な数値については書かれていない。

この記事を読んで思ったこと2つ。

1. 接続で15ms節約したところで、結局あのうざい「しつこい確認画面」で20秒待たされるんじゃ意味ないでしょ。

2. 月曜にはLLMのスクレイピングによるサーバー負荷を嘆いて「自分たちこそインターネットの守護者」みたいに振る舞っておきながら、火曜には自分たちが数マイクロ秒節約するために、全オリジンに無意味なリクエストを送りつけてる。引用：「TLS 1.3対応のオリジンそれぞれに対して、X25519、P-256、P-384、P-521、X25519MLKEM768といった各鍵交換グループを1つずつ提示する軽量なTLSハンドシェイクを何度か実行します。[...] また、アクティブスキャンは本番トラフィックの外で行われるため、実際のトラフィックが依存する前に、オリジンと中間のネットワークがより強力な鍵交換による接続を処理できるかを確認できます」だってさ。

Cloudflareは、インフラを「なんとなくコードを書く（vibe-coding）」だけじゃどうにもできないことを示す典型例だね。そもそもこの最適化が必要だと知ること、ましてやそれを構築する能力を持つことなんて、相当な規模で運用しないと気づかない。もちろん、Cloudflareレベルの規模になればコーディングエージェントを使って実装するのもアリだろうけど、そうじゃない環境でその必要性に気づくなんて、運が良くないと無理だよ。

どんな種類のSaaSで働いていようと、規模が唯一の防御策になる未来がどうなるかを考えておくのは価値があることだと思う。