TLSのパフォーマンス：QUICとHTTP/3

HTTP/2は単一のTCP接続上で複数のストリームを多重化し、HTTP/1.1における接続ごとのヘッドオブラインブロッキングを解消します。しかし、TCP自体はトランスポート層でヘッドオブラインブロッキングを引き起こします。1つのTCPセグメントが失われると、キュー内でその後ろにあるすべてのデータが再送を待つことになり、すべてのHTTP/2ストリームが同時にブロックされます。パケット損失率が1%になると、複数の接続を使用するHTTP/1.1よりもHTTP/2の性能が低下する場合があります。QUIC (Quick UDP Internet Connections) は、UDP上で多重化ストリームを実装することでこの問題を解決します。ストリーム単位の損失回復が他のストリームをブロックしないためです。

QUICはUDP上に構築されたトランスポートプロトコルで、Googleによって開発され（2012～2015年）、IETFによってRFC 9000（2021年）として標準化されました。QUICはトランスポート層にTLS 1.3を統合しています。QUICの上に別個のTLSハンドシェイクがあるのではなく、TLS自体がQUICのハンドシェイクに組み込まれています。QUICは、ヘッドオブラインブロッキングのない多重化ストリーム、接続移行（WiFiからLTEへの切り替えなど、ネットワークを変更しても接続を維持する機能）、再接続時の0-RTT接続確立、組み込みの損失検出と輻輳制御を提供します。HTTP/3（RFC 9114）は、QUICストリーム上でHTTPセマンティクスを提供するプロトコルです。

QUICのハンドシェイクは、接続の確立とTLSネゴシエーションを組み合わせたものです。最初のフライト（QUICの用語では0 RTT）で、クライアントはTLS ClientHelloを含むInitialパケットを送信します。サーバーは独自のInitial（ServerHello）と、Handshakeパケット（暗号化された拡張、証明書、Finished）を返します。クライアントはHandshake Finishedを送信し、その後アプリケーションデータを送信できる状態になります。これが1-RTTです。0-RTT接続では、クライアントはClientHelloとともに0-RTTパケット（アプリケーションデータ）を送信します。これは前回のセッションの再開シークレットから導出した鍵を使用するため、キャッシュされたセッションでは追加のラウンドトリップが不要になります。

QUICは、TLSの鍵スケジュールの各段階に対応する4つの異なる暗号化レベルを使用します。Initial（既知の定数鍵から導出されたQUIC用のAEADを使用し、完全性は提供しますが、高度な攻撃者に対する機密性は提供しません）、Handshake（TLSのhandshake_secretから導出され、TLSハンドシェイクメッセージの機密性を提供します）、0-RTT（前回のセッションのearly_secretから導出され、0-RTTアプリケーションデータを暗号化します）、1-RTT（TLSのmaster_secretから導出され、すべてのアプリケーションデータを暗号化します）です。QUICヘッダーは部分的に暗号化されます。パケット番号とペイロードは暗号化されますが、ロードバランサー向けに一部のルーティング情報（Connection ID）は可視のままです。

QUIC接続は、4タプル（src IP、src port、dst IP、dst port）ではなく、Connection ID（CID）によって識別されます。これにより、ネットワークが変わっても接続を維持できます。モバイルクライアントがWiFiからLTEに切り替えるとIPアドレスは変わりますが、CIDは同じままです。クライアントは新しい経路でPATH_CHALLENGEフレームを送信し、サーバーはPATH_RESPONSEを返して新しいアドレスを検証します。再ネゴシエーションなしで、接続はシームレスに継続します。TCPではこれをサポートできません。TCP接続は4タプルに紐付けられているため、ネットワークが変わると再確立する必要があり、新しいTLSハンドシェイクも必要になります。QUICの移行機能は、モバイルユーザーの体感性能を大幅に向上させます。

HTTP/3はHTTPのセマンティクスをQUICストリームにマッピングします。各HTTPリクエストとレスポンスの組は、個別の双方向QUICストリームを占有します。QUICストリームは独立しているため、ストリーム3での損失がストリーム7をブロックすることはありません。HTTP/3はヘッダー圧縮にQPACK（HTTP/2のHPACKに代わるもの）を使用します。QPACKは、順序どおりの配信を必要とせずに動作するよう再設計されています。専用の単方向制御ストリームが2つあり、設定とデコーダー／エンコーダー命令を伝送します。HTTP/3のサーバープッシュでは、プッシュストリーム（単方向）を使用します。全体として、HTTP/3はパケット損失が発生する状況（モバイルネットワークや混雑した経路）で、TCPのヘッドオブラインブロッキングの影響が最も大きくなるため、HTTP/2を最も大幅に上回ります。

QUICとHTTP/3の実環境での性能測定結果は、ネットワーク条件によって異なり、一様ではありません。高品質なネットワーク（低遅延、低パケット損失）では、HTTP/3とHTTP/2は同程度の性能になります。QUICのオーバーヘッド（大きなヘッダーやUDP処理のオーバーヘッド）により、HTTP/3の方がわずかに遅くなる場合さえあります。パケット損失率が1%を超える、モバイルや衛星通信でよく見られる損失の多いネットワークでは、HTTP/3はHTTP/2を大幅に上回ります。Googleは、QUICへの切り替えによりYouTubeの再バッファリングが7～8%減少したと報告しました。Facebook（Meta）は、QUICを使用したInstagramフィードで、リクエストレイテンシが7～15%改善したと報告しました。効果が最も明確に現れるのはテールレイテンシ（p95、p99）です。ここではTCPの再送による停止が最も大きな影響を及ぼします。

QUICはUDPベースであり、ステートレスなUDPロードバランサーでは接続アフィニティを実現できないため、QUICのロードバランシングはTCPより複雑です。IETFのdraft-ietf-quic-load-balancersでは、サーバーがConnection IDにルーティング情報を埋め込む方式を定義しています。これにより、ロードバランサーは接続ごとの状態を追跡せずに、同じ接続からのパケットを同じサーバーへルーティングできます。Connection IDには、ロードバランサーとサーバー間で共有する鍵を使って暗号化されたサーバーIDが含まれます。Cloudflare、Fastly、Nginxは、この方式の派生実装を提供しています。NATトラバーサルも別の課題です。QUIC接続はNATリバインディング後も維持する必要があり、これは接続移行の仕組みによって処理されます。

主要なCDNでは、QUICとHTTP/3が大規模に導入されています。Cloudflareは2019年からHTTP/3を提供しており、クライアントとサーバーの両方が対応している場合、トラフィックの約20%がQUICを使用すると報告しています。Fastly、Akamai、AWS CloudFrontは、エッジでHTTP/3をサポートしています。Google独自のインフラ（Search、YouTube、Gmail）では、2013年から社内でQUICを使用しており、HTTP/3を一般公開しています。CDNでの導入では、QUICの0-RTT再開が有効です。繰り返し訪れるユーザーはより速く接続を確立でき、接続移行によって、コンテンツ配信中にモバイルユーザーがアクセスポイント間を移動する場合の性能も向上します。

QUICのUDPベースの設計には、特有のセキュリティ上の考慮事項があります。増幅攻撃では、攻撃者が送信元IPを偽装して小さなInitialパケットを送信し、サーバーに大きなHandshakeレスポンスを被害者へ送信させる可能性があります。QUICは、アドレスの検証が完了するまで（RETRYメカニズムを介して）、サーバーからの応答を受信データの3倍に制限することで、この攻撃を緩和します。接続フラッディングに対しては、QUICサーバーで同じIPアドレスからの新規接続試行をレート制限する必要があります。バージョンネゴシエーション攻撃は、暗号学的に保護されたハンドシェイクにバージョンを含めることで防止されます。QUICには組み込みの暗号化があるため、検査アプライアンスがQUICペイロードを分析するには、サーバー証明書を持って経路上に存在する必要があります。これにより、検査可能なTCPトラフィックと比べてプライバシーが向上します。

HTTP/3のデプロイには、次のものが必要です。(1) QUIC対応サーバー（nginx 1.25+、Caddy、HAProxy 2.6+、LiteSpeed、またはquic-go、aioquic、ngtcp2ライブラリを介したアプリケーションレベルの実装）。(2) ファイアウォールでUDPポート443を開放すること。多くの企業ファイアウォールはUDP 443をブロックするため、QUICはTCP/TLSへフォールバックします。(3) レスポンスヘッダーであるAlt-Svcを使ってHTTP/3のサポートを通知すること：Alt-Svc: h3=":443"; ma=86400。これにより、HTTP/2クライアントにアップグレードを促します。(4) QUIC対応ロードバランサー、またはL4 UDPパススルー。(5) 接続移行イベント、0-RTT受け入れ率、プロトコルフォールバック率など、QUIC固有のメトリクスを監視すること。HTTPSへのフォールバックを用いた段階的な展開により、QUICに対応していないクライアントにも透過的に対応できます。

QUICは、TCP上のHTTP/2に影響するヘッドオブラインブロッキングの問題をどのように解決しますか。

QUICはUDP上のトランスポート層にTLS 1.3を統合し、ストリームごとに独立した損失回復を行うことで、TCPのヘッドオブラインブロッキングを排除します。Connection IDにより、再ネゴシエーションなしでネットワークの変更をまたいだ移行が可能になります。HTTP/3は、QPACKヘッダー圧縮を使用してHTTPをQUICストリームにマッピングします。0-RTT接続再開では、TLSセッションシークレットを再利用します。QUICは、パケット損失が発生する状況（モバイルネットワークや混雑したネットワーク）でHTTP/2を最も大幅に上回ります。QUICのロードバランシングでは、Connection IDにサーバーへのルーティング情報を埋め込む必要があります。デプロイにはUDP 443、QUIC対応サーバー、プロトコルを通知するAlt-Svcヘッダーが必要です。