QUIC と HTTP/3 とは何ですか?

QUIC (Quick UDP Internet Connections)は、柔軟性、組み込みのセキュリティ、パフォーマンスの問題の少なさ、採用率の速さにより、伝送制御プロトコル (TCP) を置き換えるように設計された汎用トランスポート層プロトコルです。 QUIC はもともと Google によって開発され、クライアントとサーバー間でパケットを移動するための低レベルのトランスポート メカニズムとしてユーザー データグラム プロトコル (UDP) を使用します。 特に、QUIC は HTTP/1.1 や HTTP/2 のような追加レイヤーではなく、トランスポート層セキュリティ (TLS) を不可欠なコンポーネントとして組み込んでいます。

QUIC をベースにした HTTP/3 は、ハイパーテキスト転送プロトコル (HTTP) の 3 番目のメジャー バージョンであり、2022 年にIETF 標準として採用されました。 QUIC+HTTP/3 は、パフォーマンスとユーザー エクスペリエンスを制限する TCP 固有の制限を解決するために作成されました。

API はどのように機能しますか?

API はアプリケーションの「公開面」であり、アプリケーションが実行する機能と提供できる情報を明らかにし、リクエストの適切な形式を定義します。 開発者がアプリケーションの API を作成して公開すると、他のアプリケーションがそのアプリケーションと通信できるようになります。

多くの場合、API はよく使用される機能をすぐに利用できるようにするため、開発者の貴重な時間を節約します。 既存のアプリケーションの機能を複製するのではなく、開発者は既存のアプリケーションの API を呼び出すことで、その機能をアプリケーションに統合できます。

HTTP ダイアグラム

HTTP トランスポート スタックの概要

QUIC+HTTP/3 の基礎

QUIC の目標は、HTTP/3 向けに高性能、高信頼性、高セキュリティのトランスポート プロトコルを提供することです (ただし、QUIC は非 HTTP トラフィックにも適しています)。

QUIC を初めて使用する場合は、以下の紹介ビデオを視聴することをお勧めします。

UDP、TCP、TLS について

UDP は、最初の接続を確立するために TCP のような複雑な 3 ウェイ ハンドシェイクを必要としない、シンプルで軽量なプロトコルです。 このシンプルさにより、UDP は高速かつコネクションレスになりますが、TCP と比較すると信頼性が高く安全な通信に不可欠な機能が欠けていることも意味します。

QUIC は、UDP プロトコルと TCP プロトコルの両方の利点を融合している点でユニークです。 これはコネクションレスであり、低レベルのトランスポート プロトコルとして UDP を活用して接続とトランスポートの遅延を削減しますが、パケット配信を保証する TCP の接続確立と損失検出機能を再実装しているため、上位層ではコネクション指向です。 失われたデータを識別し、再送信を完了するタスクを処理して、シームレスなユーザー エクスペリエンスを保証します。

QUIC は、HTTP/1.1 や HTTP/2 の場合のように追加レイヤーとしてではなく、不可欠なコンポーネントとして TLS を組み込んでいます。 この組み込みにより、メッセージがデフォルトで暗号化されるようになります。

QUIC ネットワークの概要

以下の図は、QUIC ネットワークの基本的な構造を示しています。 図に示されているように、HTTP/3 リクエスト、レスポンス、またはアプリケーション データを含む論理オブジェクトは QUICストリームです。 ネットワーク エンドポイント間の送信では、QUIC ストリームは複数の論理レイヤー内にラップされます。

Quic のネットワーク構造図

QUIC ストリームの構造

外側から内側に向かって、論理レイヤーとオブジェクトは次のようになります。

  • UDP データグラム – 送信元ポートと宛先ポートを指定するヘッダー(長さとチェックサム データを含む)と、それに続く 1 つ以上の QUIC パケットが含まれます。 データグラムは、ネットワークを介してクライアントからサーバーに送信される情報の単位です。
  • QUIC パケット – 1 つの QUIC ヘッダーと 1 つ以上の QUIC フレームが含まれます。
  • QUIC ヘッダー – パケットに関するメタデータが含まれます。 ヘッダーには 2 つの種類があります。
    • 接続の確立時に使用される長いヘッダー。
    • 接続が確立された後に使用される短いヘッダー。 これには、接続 ID、パケット番号、キー フェーズ (キー ローテーションをサポートするために、パケットの暗号化に使用されたキーを追跡するために使用される) などのデータが含まれます。 パケット番号は、特定の接続とキー フェーズごとに一意であり (常に増加します)。
  • フレーム – タイプ、ストリーム ID、オフセット、ストリーム データが含まれます。 ストリーム データは複数のフレームに分散されていますが、接続 ID、ストリーム ID、およびオフセットを使用して組み立てることができ、これを使用してデータ チャンクを正しい順序で表示できます。
  • ストリーム – 単一の QUIC 接続内での一方向または双方向のデータ フロー。 各 QUIC 接続は、それぞれ独自のストリーム ID を持つ複数の独立したストリームをサポートできます。一部のストリームを含む QUIC パケットが失われた場合でも、失われたパケットに含まれていないストリームの進行には影響しません (これは、HTTP/2 で発生するヘッドオブライン ブロッキングを回避するために重要です)。 ストリームは双方向であり、どちらのエンドポイントでも作成できます。
QUIC が TLS ハンドシェイクでどのように機能するか

TLS ハンドシェイクは、クライアントとサーバー間の安全な接続を提供します。 QUIC が提供する暗号化にはTLS v1.3 が必要です。 下の図に示すように、QUIC は暗号鍵を提供する TLS「コンテンツ レイヤー」を維持しますが、「レコード レイヤー」を独自のトランスポート メカニズムに置き換えます。

QUIC は、セキュリティとパフォーマンスに重要なパラメータの認証とネゴシエーションにも TLS に依存しています。 厳密な階層化ではなく、2 つのプロトコルが連携します。 QUIC は TLS ハンドシェイクを使用して安全な接続を確立しますが、TLS は QUIC が提供する信頼性、順序付き配信、およびレコード レイヤーを使用します。

大まかに言えば、TLS コンポーネントと QUIC コンポーネントの間には主に 2 つの相互作用があります。

  • TLS コンポーネントは QUIC コンポーネントを介してメッセージを送受信し、QUIC は TLS に信頼性の高いストリーム抽象化を提供します。
  • TLS コンポーネントは、(a) インストールする新しいパケット保護キー、(b) ハンドシェイクの完了、サーバー証明書などの状態の変更など、QUIC コンポーネントに対する一連の更新を提供します。

QUIC TLS の HTTP/3 サポート オプション

QUIC TLS は、QUIC プロトコル専用に設計された TLS のバリエーションです。 現在、QUIC TLS で HTTP/3 サポートを探しているユーザーには 2 つのオプションがあります。

  • OpenSSL QUIC 実装– OpenSSL は現在、完全な QUIC スタックを独自に実装することに取り組んでいます。 この開発により、実装内のすべての QUIC 機能がカプセル化され、HTTP/3 ユーザーは QUIC 固有の機能を気にすることなく OpenSSL TLS API を簡単に使用できるようになります。
  • BoringSSL QUIC API をサポートするライブラリ – BoringSSL、quicTLS、LibreSSL (OpenSSL のフォークとして開始) などのさまざまな SSL ライブラリは、現在、BoringSSL QUIC API を実装することで QUIC TLS 機能を提供しています。OpenSSL QUIC TLS 実装はまだ準備ができていないため、HTTP/3 を使用したいユーザーにとってこれが現在のところ唯一のオプションです。
QUIC+HTTP/3 の利点

QUIC+HTTP/3 は、遅延を減らし、信頼性の低いネットワーク上でのデータ配信を改善することで、Web アプリケーションのパフォーマンスを向上させることを目的としています。 それらの利点は次のとおりです。

  • 遅延の削減 – TCP などの従来のプロトコルでは、接続セットアップ プロセスが原因で遅延が発生します。 QUIC + HTTP/3 の多重化機能により、より効率的に接続を確立できるため、接続の確立とデータ転送の待ち時間が短縮されます。
  • より高速な接続の確立 - QUIC+HTTP/3 は、TLS ハンドシェイクと暗号化の設定を 1 つのステップに統合し、安全な接続を確立するために必要なラウンドトリップの回数を削減します。
  • 多重化 - QUIC+HTTP/3 では、単一の接続内で複数のデータ ストリームを処理することで、ネットワーク リソースをより効率的に使用できるようになり、従来の TCP 接続で 1 つの低速ストリームが他のストリームを遅延させる可能性があるヘッドオブライン ブロッキングの問題を回避するのに役立ちます。
  • 改善されたエラー訂正 – QUIC には前方誤り訂正技術が組み込まれており、再送信を必要とせずに失われたパケットを回復できるため、パケット損失によるパフォーマンスへの影響を軽減できます。
  • パケット損失の影響の軽減 - UDP はコネクションレス型であり、TCP のような厳密なエラーチェックを必要とせず、より高速な伝送を可能にします。 これは、ネットワーク状態があまり安定していないシナリオで特に有利です。
  • 適応型輻輳制御 - QUIC + HTTP/3 は、TCP の輻輳制御よりも効率的で応答性が高くなるように設計されており、さまざまなネットワーク環境でパフォーマンスが向上します。
  • 移行サポート – QUIC + HTTP/3 は、アプリケーションのパフォーマンスを中断することなく、異なるネットワーク接続 (Wi-Fi からセルラーへの切り替えなど) 間をシームレスに移行できます。
  • セキュリティの向上 - QUIC+HTTP/3 はデフォルトで暗号化を統合し、データ転送のセキュリティとプライバシーを強化します。 この暗号化により、転送中のデータの盗聴や改ざんが防止されます。
  • NAT トラバーサル – QUIC + HTTP/3 の UDP の使用は、ネットワーク アドレス変換 (NAT) トラバーサルに役立ち、従来の TCP 接続で問題が発生する可能性があるシナリオでも接続を確立しやすくなります。
  • 絶え間ない進化 – QUIC + HTTP/3 は、基盤となるネットワーク インフラストラクチャの変更を必要とせず、ソフトウェアによって実装および更新されるように設計されているため、変化するネットワーク状況やセキュリティ上の懸念に適応するために、より迅速に更新および改善できます。
NGINX での QUIC+HTTP/3 の使用について学ぶ

以下のリソースを参照して、NGINX の QUIC+HTTP/3 実装と、QUIC+HTTP/3 を使用してより高速で効率的な通信を実現するその他の方法について学んでください。