NGINX.COM
Web Server Load Balancing with NGINX Plus

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つのディレクティブを含めるだけです。

ディレクティブ 説明
listen 443 http3 reuseport;

http3パラメータを持つ新しいlistenディレクティブを追加して、HTTP/1.1およびHTTP/2と同じポート(この例では443)でHTTP/3接続をリスニングするようにNGINXに指示します。

reuseportパラメータは、複数のNGINXワーカープロセスが存在する場合に正しく動作するために必要です。これにより、カーネルは、着信HTTP/3接続をプロセス間で分散できます。

ssl_protocols TLSv1.3;

QUICで求められているように、受け入れるプロトコルのリストにTLS 1.3を含めます(このディレクティブはすでに設定に含まれていると思いますが、必要であれば追加してください)。

すべてのブラウザをサポートするために、古いバージョンのTLSも含める必要があります。TLS 1.3のブラウザサポートについては、「Can I use TLS 1.3?」で確認してください。

add_header Alt-Svc 'h3=":$server_port"; ma=86400';

このディレクティブを追加すると、NGINXは、QUICへのアップグレードが可能であることと、どのポートで接続するかをブラウザに指示するレスポンスヘッダーを追加します。

慣例として、このポート(この例では$server_port変数で表されます)は、HTTP/1.1およびHTTP/2でのTLSに使用されるポートと同じです。

maの値は、NGINXがUDP経由でHTTP/3トラフィックを受け入れることをクライアントが安全に判断できる秒数です。この時間を過ぎると、クライアントはTCPに戻す必要があります。ここで指定されている値は、24時間に相当します。

以下に、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ハンドシェイクを実行する必要があり、そのためにいくつかのラウンドトリップが追加されます。

Diagram comparing the messages needed for HTTP connection resumption for TCP+TLS versus QUIC

すべての新しいディレクティブと変数については、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アナウンスメーリングリストにご登録ください。

Hero image
NGINXクックブック 設定レシピ集(日本語版)

待望の【O'Reilly】NGINX Cookbook日本語版がついに完成!NGINXクックブックは、NGINXを最大限に活用する方法を解説しています。



著者について

Robert Haynes

Technical Marketing Manager

About F5 NGINX

F5 NGINXについて
F5, Inc.は、人気のオープンソースプロジェクト「NGINX」を支援しています。NGINXはモダンアプリケーションを開発・構築するためのテクノロジースイートを提供しています。NGINXとF5製品との併用で、コードからユーザーまでの広範なアプリケーション領域をサポートし、マルチクラウドアプリケーションサービスとしてNetOpsとDevOps間の課題を解決します。

詳しくはnginx.co.jpをご覧ください。Twitterで@nginxをフォローして会話に参加することもできます。