対応の告知と実際の動作は別
サーバーはAlt-SvcレスポンスヘッダーでHTTP/3への対応を告知し、クライアントはそのヘッダーをHTTP/1.1またはHTTP/2経由で受け取ります。ヘッダーはあくまで約束です。HTTP/3はUDP上のQUICで動作するため、UDPが完全に遮断されていてもページは正常に読み込まれ、ブラウザーは何も通知せずに使い続けることがあります。その場合のプロトコルはHTTP/2.
curl -sI https://server.example/ | grep -i alt-svc実際の転送を確認する
QUIC経由でリクエストが完了して初めて、確認できるのがHTTP/3. HTTP/3対応でビルドされたcurlを使ってください。多くのシステムパッケージは非対応で、その場合はオプションが拒否されますが、これはサーバーの状態を示すものではありません。ブラウザーでは開発者ツールを開き、プロトコルの列を確認します。該当するリクエストにはh3と表示されます。初回のアクセスではHTTP/2が使われることがあるため、ページを再度読み込んでください。
curl -V | grep -i http3
curl -sS --http3-only -o /dev/null -w '%{http_version}\n' https://server.example/NGINXの設定を確認する
NGINXにはTCPのリスナーに加えてQUICのリスナーが必要で、使用するバージョンとビルドが対応していなければなりません。QUICが直接利用するTLS 1.3も必須です。再読み込みの前に設定を確認してください。Alt-Svcのma値は、クライアントがこの約束を記憶する秒数なので、テスト中は短い値を使います。
listen 443 ssl;
listen 443 quic reuseport;
http2 on;
add_header Alt-Svc 'h3=":443"; ma=300' always;
nginx -V 2>&1 | grep -o with-http_v3_module
sudo nginx -t経路全体でUDP 443を許可する
最も多い失敗原因は、TCP 443を許可していてもUDP 443を許可していないファイアウォールです。サーバーとすべての外部フィルターを確認してください。ソケットが待ち受けているかどうかはサーバー側で確認できます。一部の企業ネットワークや公共ネットワークは意図的にQUICを遮断しているため、1つのネットワークからのテスト失敗だけではサーバー側の問題とは断定できません。別のネットワークから再度テストしてください。
sudo ss -lunp | grep ':443'
sudo ufw allow 443/udp
sudo tcpdump -ni any udp port 443新しいプロトコルは速いのか
HTTP/3が特に役立つのは、パケット損失のある接続やネットワークを切り替える場合です。パケットが失われても他のストリームを待たせないためです。良好な有線接続では差が小さいことがあり、サーバーのCPU使用率が高くなる場合もあります。効果を決めつけず、自分の環境で測定してください。UDPを使えないクライアントのためにHTTP/2も利用できる状態にしておきます。
CH-J Server ManagerのHTTP/3テスト
Server DiagnosticsにはHTTPクライアントが同梱されているため、テストはシステムのcurlに依存しません。QUIC転送が完了した場合にのみHTTP/3を確認済みとし、Alt-Svcは対応の告知としてのみ扱います。UDPがタイムアウトした場合は、原因がクライアントとサーバーの間のネットワークにある可能性があるため、サーバーの対応状況は未確認と表示します。別のプロトコルへのフォールバックは成功とは数えません。