ブログ | NGINX

プレビュー版 NGINX QUIC+HTTP/3 実装のバイナリ パッケージが利用可能になりました

NGINX-F5 水平黒タイプ RGB の一部
ロバート・ヘインズ サムネイル
ロバート・ヘインズ
2023年2月8日公開

[編集者: NGINX は、QUIC を使用した HTTP/3 を正式にサポートするようになりました。オープンソース ユーザー向けの NGINX 1.25.1 メインライン バージョンと、エンタープライズ ユーザー向けのNGINX Plus R30の一部として利用できます。
[ngx_snippet name='テーブルスタイルブログ']
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 Open Sourceをダウンロードしてビルドすることができます。コードは実験的とされていますが、コミュニティのメンバー数名から、 nginx-quic を本番環境で正常に使用しているとの報告があります。

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

執筆時点では、オープンソース SSL/TLS の事実上の標準である OpenSSL は QUIC をサポートしていません。そのため、依存関係として自動的にインストールされるquictlsライブラリ パッケージを使用してバイナリ ディストリビューションをビルドします。 現時点では安定性、互換性、機能の最適な組み合わせを表しているため、quictls を選択しました。

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

QUIC+HTTP/3 用の NGINX の設定

QUIC+HTTP/3 用に NGINX を構成するための新しいディレクティブがいくつかありますが、既存の仮想サーバー ( server{} ) 構成ブロックでそれらを HTTP/1.1 および HTTP/2 のディレクティブと組み合わせるのは簡単です。

最も基本的な機能構成では、 server{} (および子のlocation{} ) ブロックに次の 3 つのディレクティブを含めるだけです。

指令説明
聞く443クイック再利用レポート;

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

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

ssl_プロトコルTLSv1.3;

QUIC の要件に従って、受け入れられるプロトコルのリストに TLS 1.3 を含めます。 (このディレクティブはおそらくすでに構成に存在しますが、必要に応じて追加してください。)

すべてのブラウザをサポートするには、古い TLS バージョンも含める必要がある可能性があります。 TLS 1.3 のブラウザ サポートの詳細については、 「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 { # 互換性を高めるために、QUIC と TCP に同じポート番号を使用することをお勧めします
listen 443 quic reuseport; # QUIC
listen 443 ssl; # TCP

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

location / {
# 設定されたポートで QUIC が利用可能であることを通知します
add_header Alt-Svc 'h3=":$server_port"; ma=86400';

#proxy_pass <上流グループ>; 
        #根       /<ルートディレクトリ>; 
}
}

オプションの HTTP/3 関連のディレクティブと変数がいくつかあります (スニペットには表示されていません)。

  • $http3 – (変数) HTTP/3 セッション中にリクエストが送信される場合はh3に設定されます (それ以外の場合は空の文字列になります)。
  • quic_retry – (ディレクティブ) onに設定すると、NGINX は、リクエスタの IP アドレスを検証する目的で、使用する新しい接続 ID を指定して QUIC 再試行メッセージをリクエスタに送り返すように指示します。 QUIC 再試行パケットは、QUIC が UDP 上で実行されるため、TCP 3 ウェイ接続ハンドシェイクを使用して接続を検証できないという事実を部分的に補います。
  • ssl_early_data – (ディレクティブ) onに設定すると、そのクライアントからの以前の接続があった場合、新しい TLS 1.3 接続を介してクライアントから送信された最初のリクエストでアプリケーション データを受け入れるように NGINX に指示します。 これは、ゼロラウンドトリップ時間 (0-RTT) 接続再開と呼ばれます。 「早期データ」の送信のサポートはTLS 1.3の機能であり、TLS ハンドシェイクに必要な余分な往復メッセージ交換を排除することで、QUIC + HTTP/3 のパフォーマンスの向上に貢献します。

    注記: 0-RTT 接続再開では、初期データにGET以外の HTTP リクエスト メソッドが含まれている場合、リプレイ攻撃の対象となるため、セキュリティ リスクが生じる可能性があります。 詳細については、弊社ブログの「NGINX Plus R17 の発表」TLS 1.3 に関するセクションを参照してください。

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

すべての新しいディレクティブと変数の詳細については、 3 を参照してください。 構成 のセクション nginx クイック README

QUIC+HTTP/3 を使用した NGINX のテスト

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

QUIC 対応サイトがブラウザからの HTTP/3 接続要求を満たしているかどうかを確認するには、ブラウザの開発者ツールを使用して、NGINX から返される HTTP ヘッダーを調べます。NGINX が TCP 経由のブラウザの最初の HTTP 要求に対する応答に上記のAlt-Svcヘッダーを含める場合、QUIC+HTTP/3 実装は正しく動作しています。

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

以下は、カスタム HTTP ヘッダーがX-protocolであるサンプルのlocationブロックです。

location / { # 設定されたポートで QUIC が利用可能であることを通知します 
add_header Alt-Svc 'h3=":$server_port"; ma=86400'; 

# QUIC+HTTP/3 を使用しているかどうかを通知します 
add_header X-protocol $server_protocol always; 

#proxy_pass <上流グループ>; 
    #根 /<ルートディレクトリ>; 
}

あるいは、使用中のプロトコルを視覚的に示す Chrome HTTP インジケーター拡張機能などのツールもあります。 (これはブラウザ拡張機能を推奨するものではないことに注意してください。拡張機能のセキュリティへの影響が状況に応じて許容できるものであることをご自身で確認する必要があります)。

次は何か

今後数週間で、QUIC+HTTP/3 向けのソリューションの提供を継続し、NGINX 最適化のさらなる例を提供していきます。 それまでの間、当社の判断に役立てていただくために、ご自身のテスト結果を共有してください。 NGINX 開発メーリング リストNGINX コミュニティ Slack#quic‑http3チャネルでフィードバックを共有できます。

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

ウェビナーを見る

また、2023 年 4 月 19 日水曜日に開催されるウェビナー「NGINX と QUIC+HTTP/3 を実際に体験する」にもぜひご参加ください。

  • 北米– 午前10時(太平洋標準時)
  • EMEA – 午前11時(中央ヨーロッパ標準時)
  • APCJ – 午前10時(シンガポール時間)

「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"