QUIC+HTTP/3対応のNGINXプレビュー実装版バイナリパッケージのご紹介

QUIC+HTTP/3対応のNGINXサポートのプレビュー実装版が、以下の2つのディストリビューション向けのビルド済みバイナリパッケージとして利用可能になったことをお知らせします。

• Red Hat Enterprise Linux 9とバイナリ互換のバリアント
• Ubuntu 22.04

このバイナリは、プレビュー実装をホストする個別のnginx-quicリポジトリのquicブランチから提供される最新のパッケージです。私たちがNGINXでのQUIC+HTTP/3対応を始めて以来そうであったように、QUIC+HTTP/3、およびQUICをサポートするSSL/TLSライブラリの選択肢を備えたNGINXオープンソースをダウンロードして構築できます。これは実験的なコードではありますが、コミュニティメンバーから、nginx-quicを本番環境で問題なく使用できているという報告を受けています。

ビルド済みバイナリをリリースする主な動機は、QUIC+HTTP/3でのNGINXテストをより迅速かつ簡単にすることです。このバイナリは、ソースからコンパイルする必要がなく、標準的なパッケージ管理ツールを使ってインストールできます。

この記事の作成時点では、オープンソースのSSL/TLSにおける事実上の標準であるOpenSSLは、QUICをサポートしていません。そのため、このバイナリディストリビューションは，依存関係として自動的にインストールされるquictlsライブラリパッケージを含めて構築しました。quictlsを選択した理由は、現時点で安定性、互換性および機能のバランスが最適であったためです。

バイナリディストリビューションのインストール方法は、NGINX QUICのWebサイトから入手できます。

NGINX for QUIC+HTTP/3の設定

NGINX for QUIC+HTTP/3を設定するための新しいディレクティブがいくつかありますが、既存の仮想サーバー（server{}）設定ブロックのHTTP/1.1およびHTTP/2用のディレクティブと組み合わせるだけです。

最も基本的な機能の設定としては、server{}（および子location{}）ブロックに以下の3つのディレクティブを含めるだけです。

以下に、server{}ブロックの例を示します。

server {
    # for better compatibility we recommend
    # using the same port number for QUIC and TCP
    listen 443 http3 reuseport; # QUIC
    listen 443 ssl;             # TCP

    ssl_certificate     certs/example.com.crt;
    ssl_certificate_key certs/example.com.key;
    ssl_protocols       TLSv1.3;

    location / {
        # advertise that QUIC is available on the configured port
        add_header Alt-Svc 'h3=":$server_port"; ma=86400';

        #proxy_pass <upstream_group>;
        #root       /<root_directory>;
    }
}

この例には示されていない、HTTP/3関連する新しいオプションのディレクティブと変数がいくつかあります。

• $http3 – （変数）リクエストがHTTP/3セッション時に送信されるとh3に設定されます（それ以外の場合は空の文字列です）。
• quic_retry – （ディレクティブ）onに設定すると、要求者のIPアドレスを検証するために、使用する新しい接続IDを指定するQUIC再試行メッセージを要求者に送り返すようNGINXに指示します。QUICはUDP経由で実行されるため、TCP 3ウェイ接続ハンドシェイクを接続の検証に使用することはできません。QUIC再試行パケットは、これを部分的に補います。

• ssl_early_data – （ディレクティブ）onに設定すると、以前接続があったクライアントから新しいTLS 1.3接続でリクエストが送られた場合にアプリケーションデータを受け入れるようにNGINXに指示します。これは、ゼロラウンドトリップタイム（0 RTT）接続再開として知られています。「早期データ」の送信のサポートは、TLS 1.3の機能であり、TLSハンドシェイクに必要な余分なラウンドトリップメッセージ交換を排除することによって、QUIC+HTTP/3パフォーマンスが向上します。

  注：0 RTT接続再開をオンにすると、GET以外のHTTPリクエストメソッドを含む場合に、早期データがリプレイ攻撃の対象となるため、セキュリティリスクが発生する可能性があります。詳しくは、当社ブログ「Announcing NGINX Plus R17」（NGINX Plus R17の紹介）のTLS 1.3に関するセクションをご覧ください。

この図は、QUIC+HTTP/3での0 RTT接続再開により、どのようにパフォーマンスが向上するかを示しています。ここでは、クライアントは、NGINXへのQUIC接続を再開するときに、最初のメッセージでHTTPリクエストを送信できます。一方、TLSのTCPの場合、クライアントは、安全な接続を確立するためにNGINXと新たにTLSハンドシェイクを実行する必要があり、そのためにいくつかのラウンドトリップが追加されます。

すべての新しいディレクティブと変数については、nginx-quicのREADMEの「3. 設定」セクションをご覧ください。

QUIC+HTTP/3でのNGINXのテスト

前述のように、ビルド済みバイナリをリリースする動機の1つは、NGINXがHTTP/3トラフィックを正しく処理していることを簡単にテストできるようにすることです。単純なコマンドラインテストでは、HTTP/3をサポートするcurlをビルドするか、ビルド済みコンテナを使用できます。さらに、ほとんどのブラウザの新しいバージョンでは、QUIC+HTTP/3をサポートしています。

QUICを有効にしたサイトがブラウザからのHTTP/3接続リクエストを満たしていることを確認するには、ブラウザの開発者ツールを使用して、NGINXから返されるHTTPヘッダーを調べることができます。TCPを介したブラウザの最初のHTTPリクエストに対する応答に、上記のAlt-Svcヘッダーが含まれていればQUIC+HTTP/3実装は正しく動作しています。

その時点で、QUIC対応ブラウザは、Alt-Svcディレクティブで指定されたポートでQUIC接続を行い、その後のHTTPリクエストとレスポンスはQUIC経由で行われます。QUIC+HTTP/3が使用されていることを確認するもう1つの方法は、別のadd_headerディレクティブを含め、カスタムHTTPヘッダーの値を$server-protocol変数で取得されたプロトコルに設定することです。ヘッダーの値は、QUIC接続が確立される前のHTTP/1.xから、QUICが使用されているときのHTTP/3.0に変わることを追跡できます。

以下に、カスタムHTTPヘッダーがX-protocolであるlocationブロックの例を示します。

location / {
    # advertise that QUIC is available on the configured port
    add_header Alt-Svc 'h3=":$server_port"; ma=86400';

    # signal whether we are using QUIC+HTTP/3
    add_header X-protocol $server_protocol always;

    #proxy_pass <upstream_group>;
    #root /<root_directory>;
}

また、ChromeのHTTP Indicator拡張機能のように、使用されているプロトコルを視覚的に表示するツールもあります（注：ブラウザの拡張機能を推奨しているわけではありません。拡張機能がもたらす可能性のあるセキュリティ上の影響が環境で受け入れられるかどうかはご自身で確認してください）。

今後の予定

これからも、QUIC+HTTP/3に対応するソリューションを提供し続け、NGINXの最適化に関するより多くの事例を提供していきます。皆様からも、テスト結果をお知らせください。今後に役立ててまいります。NGINX開発メーリングリストおよびNGINXコミュニティSlackの#quic‑http3チャンネルでフィードバックを共有できます。

次の重要なマイルストーンであるnginx-quicリポジトリのメインラインのNGINXオープンソースブランチへのマージなど、QUIC+HTTP/3への対応に関する最新情報を入手したい方は、NGINXアナウンスメーリングリストにご登録ください。