HTTP/3とQUIC：最新のWeb通信の仕組み

HTTP/3は、おなじみのHTTP/2・TLS・TCPの組み合わせに代えてQUICを使うHTTPのバージョンです。QUICはUDP上で動作しますが、信頼性のあるストリーム、輻輳制御、安全な接続の確立といった機能を備えています。ただし、HTTP/3に対応しただけで、どのページも速くなるわけではありません。

HTTP/2から変わる点

GETなどのメソッドやレスポンスコードの意味はこれまでどおりで、変わるのはメッセージの運び方です。HTTP/2は、1本のTCPコネクション上で複数のストリームを多重化します。そのため、TCPのセグメントがひとつ欠けると、トランスポート層でほかのストリームのデータまで配信が遅れることがあります。QUICは複数のストリームを自ら管理するので、あるストリームでロスが起きても、同じようにほかのストリームが足止めされることはありません。ロスの多いネットワークでは効果が期待できますが、物理的な距離や遅いサーバーの問題までは解消できません。

QUICは、TLS 1.3をベースにしたセキュリティをハンドシェイクに組み込んでいます。「UDP上で動く」といっても、ページの内容が平文で送られるわけではなく、HTTP/3は保護された接続を使います。2回目以降の接続では、クライアントとサーバーがすでに持っている情報しだいで、接続確立にかかる遅延の一部を省けることがあります。その効果は実装やネットワークの状況によって変わり、決まった速度向上が得られるわけではありません。

443番ポートとフォールバック

HTTP/3では一般にUDPの443番ポートを、HTTP/2によるHTTPSでは一般にTCPの443番ポートを使います。ネットワークのファイアウォールがUDPをブロックしていると、QUICの接続を開始できないことがあります。その場合、クライアントはTCP上の別の対応バージョンのHTTPを使えます。つまり、UDPの443番をブロックしてもサイトにアクセスできなくなるとは限りませんが、パフォーマンスが変わったり、原因の切り分けが難しくなったりすることはあります。TCP 443番のポートテストの結果では、HTTP/3に対応しているかどうかはわかりません。

ブラウザーの開発者ツールでは、個々のリクエストで使われたプロトコルを確認できます。ホスティング事業者の機能一覧だけを当てにしないでください。CDN、リバースプロキシ、ページに埋め込まれたリソースは、それぞれ別の接続を使っている可能性があります。稼働中のサイトを確認するには、HTTP/3に対応したクライアントでリクエストを送り、実際にネゴシエートされた内容を調べましょう。サイトの技術的な情報は、2IPのWebサイト情報ツールでも確認できます。

効果が期待できる場面

パケットロスが起きる場合や、モバイル端末のネットワーク経路が切り替わる場合には、実装が該当する仕組みに対応していれば、HTTP/3が役立つことがあります。一方で、大きすぎる画像、不要なスクリプト、遅いアプリケーションコードの問題は解決しません。プロトコル名だけでなく、ページの読み込みとユーザー体験を測定しましょう。詳細はHTTP/3とQUICの仕様で定義されています。土台となるトランスポートの選択については、TCPとUDPの解説記事をご覧ください。