QUICおよびHTTP/3対応のNGINXプレリリース版のご紹介

今回、特別なオープンソースリポジトリとして、QUIC + HTTP/3 for NGINXのテクノロジープレビュー版を発表いたしました。これは、IETF QUICドラフトに基づくプレリリースソフトウェアであり、stableおよびmainlineブランチから分離された開発ブランチで保守されています。 このリリースは、数か月にわたる初期フェーズにおける開発の集大成であり、相互運用性テスト、フィードバック、およびコード提供の準備が整いました。

NGINX QUIC + HTTP/3実装を有効にしたデモサイトは、https://quic.nginx.org/で お試しやダウンロードすることができます。

HTTP/3について

非常に早いペースで変化や更新が行われるテクノロジーの世界において、Hypertext Transfer Protocol（HTTP）は、20年以上も非常に安定し変わらず使い続けられているプロトコルです。HTTP/1.1標準は1999年に公開され、WebアプリケーションおよびAPIのあらゆるところで利用されるトランスポートプロトコルになりました。アプリケーションやサービスには大きな変更や革新があったにもかかわらず、HTTPはその後21年の間も変わらず支持され続けています。

では、HTTP/2についてはどうでしょうか？HTTP/2は2015年に公開され、インターネット上に公開されているWebサイトの45％がHTTP/2をサポートするにいたるまで幅広い環境で採用されています。ただし、この統計は、「ラストマイル」（アプリケーションの実行環境）と比較して、パブリックインターネット上でのHTTPの使用状況が異なっているという事実を表しています。

最新のインターネットインフラストラクチャでの現実は、HTTP/2がエンドツーエンドで展開されることは非常にまれです。HTTP/2は、パブリックのインターネット環境で頻繁に遭遇する予想以上に高いレイテンシーや、HTTPリクエストのうちある１つのデータに問題が発生した場合に後続のリクエストをさらに遅らせてしまうという大きな課題を解決するために設計されています。アプリケーションの実行環境（パブリッククラウドやプライベートデータセンターなど）内では、レイテンシーが低く、ネットワークの信頼性が優れており、HTTP/2のバイナリ形式のストリームの効率よりも、HTTP/1.1のテキストベースのトランスポートにより直接検査できることにより価値があると考えられます。

HTTP/2は、ブラウザやモバイルデバイスでのユーザーエクスペリエンスを大きく改善し、クライアントとWebアプリケーションの実行環境の「エッジ」の間の環境に適しています。その後、HTTP/1.1が使用されるアプリケーションの実行環境にプロキシされます。ここで言うエッジは、CDNプロバイダーや、実行環境宛のトラフィックを処理するリバースプロキシ型のロードバランサーなどが該当します。

Webサイトとアプリケーションを配信するためにHTTP/2とHTTP/1.1を使用して、このハイブリッドアプローチが使われており、そしてその環境でアプリケーションは効果的に動作します。では、なぜ別の新しいプロトコル、HTTP/3が必要なのでしょうか。

HTTP/2の主な革新は、第3層のトランスポートとして使用されるTCPの単一のコネクション上で複数のHTTPリクエストを多重化することです。残念ながら、TCPにはWebサイトとアプリケーションのパフォーマンスとユーザーエクスペリエンスを制約する制限があります。 TCPは1981年に公開されたことから始まり、その後、汎用のトランスポートプロトコルとして驚くほどの成功を収めています。しかし、同一コネクション上で複数のリクエストを多重化したとき、すべてのデータはそのコネクションが持つ信頼性の影響を受けます。もしあるリクエストの1つのパケットが失われた場合、パケットの消失が検出されてから再送信されるまで、多重化されたすべての要求が遅延します。

HTTP/3は、単一のTCP接続に依存せずに多重接続をサポートするように特別に設計されたQUICトランスポートプロトコルに基づいています。 QUICは代わりに、クライアントとサーバー間でパケットをやり取りするための第3層のトランスポートメカニズムとしてUDPを使用し、HTTPのリクエストをやり取りするための信頼性の優れたコネクションを実装します。特に、QUICは、HTTP/1.1やHTTP/2における追加のレイヤーとしてではなく、必須コンポーネントとしてTLSを組み込んでいます。

QUICが目指すところは、HTTP/3に高性能、高信頼性、高セキュリティのトランスポートプロトコルを提供することです。（さらに、QUICは非HTTPトラフィックにも適しています）名前が持つ意味という観点では、HTTP/3自体はHTTP/2に非常に似ています。しかし、HTTPの明示的なバージョン管理というものはなく、https://www.example.comというサイトは、HTTP/1.1、HTTP/2、およびHTTP/3の1つ以上をサポートする場合があります。では、クライアント（Webブラウザー）は、使用するHTTPのバージョンをどのようにして知るのでしょうか？

HTTPにおけるバージョンの問題は、HTTP/2を導入する際に初めて、問題として発生し、TLSハンドシェイクの際にクライアントとサーバーでHTTP/2経由の通信が可能であるか検出することにより問題を解決としました。このようにして、クライアントはコネクションを確立する前に、サーバーとどのような接続をするか知ることができるのです。しかし、基になるトランスポートプロトコルとしてTCPではなくUDPを使用するQUICは、新たな課題を発生させます。クライアントは、最初にリクエストを転送するために接続種別（TCPまたはUDP）をどのようにして知るのでしょうか。この解決策は、クライアントが最初のHTTPリクエストのためにTCPのコネクションを確立することです。HTTP/3をサポートするサーバーからの応答には、HTTP/3トラフィックをリッスンしているUDPポートを指定するAlt-Svcヘッダーが含まれています。 さらに、ブラウザはどのサイトがQUICをサポートしているかを記憶し、Alt-Svcベースの検出方法のオーバーヘッドを排除します。

NGINX QUIC + HTTP/3プレビュー

わたしたちは公式にNGINXにおけるhttp_v3_moduleを用いたQUICおよびHTTP/3の実装における最初のリリースを発表いたします。これはテクニカル・プレビュー版であり、まだ実験的バージョンです。本番環境で使用するためのものではありません。執筆時点では、QUIC 標準はまだ確定されておらず、この初期リリースは現在のドラフトのサブセットに対して実装されています。

数か月にわたる設計と開発の後、http_v3_moduleは相互運用性テストの準備ができています。また、一般的なフィードバックやコードの寄稿も歓迎します。 http_v3_moduleはmainline開発ブランチでは使用できないことに注意してください。 まだ実験段階なので、https://hg.nginx.org/nginx-quicの専用開発ブランチにあります。

このQUIC + HTTP/3の実装は完全に新しいものであり、quicheプロジェクトの一部としてCloudflareが提供するパッチとは関係ありません。

NGINX構成に慣れている人にとって、QUIC + HTTP/3を有効にするのは非常に容易になっています。

server {
    listen 443 ssl;              # TCP listener for HTTP/1.1
    listen 443 http3 reuseport;  # UDP listener for QUIC+HTTP/3

    ssl_protocols       TLSv1.3; # QUIC requires TLS 1.3
    ssl_certificate     ssl/www.example.com.crt;
    ssl_certificate_key ssl/www.example.com.key;

    add_header Alt-Svc 'quic=":443"'; # Advertise that QUIC is available
    add_header QUIC-Status $quic;     # Sent when QUIC was used
}

nginx-quicリポジトリからのNGINXの構築や、推奨される構成の詳細については、READMEを参照してください。さらに、http_v3_moduleが有効になっているデモサイトは、https://quic.nginx.org/で利用ができます。ここで、ブラウザがすでにQUICをサポートしているかどうかを確認することが可能であり、お客様がご利用される独自のnginx-quicビルドとHTTP/3の動作について比較することができます。QUICはドラフトのステータスであることを考えると、QUICを有効にするためにはブラウザーの開発バージョンまたは最新ビルドの使用が必要となる場合があります。

是非nginx-quicをお試しいただき、メーリングリストでフィードバックをお待ちしております。