LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

HTTP/3・QUICとは——UDPベースの新しいトランスポート層

HTTP/3とは、QUIC(トランスポートプロトコルの一種)の上でHTTPの意味論を実現する仕様で、IETFがRFC 9114として2022年6月に標準化しました^*1。QUIC自体はRFC 9000として2021年5月に標準化されたプロトコルで、UDPデータグラムの中にパケットをカプセル化して動作します^*2。MDNの解説でも、QUICはTCPに代わってHTTP/3で使われるマルチプレックス型のトランスポートプロトコルと位置づけられています^*3。

従来のHTTP/1.1とHTTP/2は、いずれもTCPの上でTLSを組み合わせて暗号化通信を実現していました。これに対しHTTP/3は、TCPではなくQUICを使う点が大きな変更点です^*4。QUICはユーザー空間で実装されるため、OS側のカーネル更新を待たずに機能を追加しやすい構造だとMDNは説明しています^*3。つまりHTTP/3は「HTTP/2の高速版」ではなく、通信の土台そのものを入れ替える規格だと捉えるほうが実態に近いといえます。

HTTP/1.1・HTTP/2との違い——ヘッドオブラインブロッキングの解消

HTTP/2は単一のTCP接続の中で複数のリクエストを多重化する仕組みを持ちますが、TCPは受信データを送信順に並べて上位層へ渡す設計です。このためTCP接続内のどこかでパケットが失われると、後続の全ストリームの処理がその再送を待つ状態になります^*4。これがヘッドオブラインブロッキングと呼ばれる現象です。

QUICでは各ストリームに対して独立した損失検出と再送を実装しているため、あるストリームでパケットが失われても、そのストリームだけが待ち状態になり、他のストリームは処理を継続できます^*2*3。RFC 9114でも、QUICが提供するストリーム多重化・ストリーム単位のフロー制御・低遅延のコネクション確立といった性質を、HTTP/3が活用する前提として位置づけています^*1。

三世代の違いを整理すると次のようになります。

QUICの三つの特徴——0-RTT・コネクション移行・TLS1.3統合

コネクションID方式によるコネクション移行

QUICはIPアドレスとポート番号の組ではなく、エンドポイントごとに発行するコネクションIDで接続を識別します^*2。この仕組みにより、クライアントが接続中にWi-Fiからモバイル回線へ切り替わった場合でも、同じコネクションIDを使って新しいネットワークパスへ移行できます^*2。NATの再割り当てが起きても通信を継続しやすい設計です。

ハンドシェイクに統合されたTLS1.3

QUICは専用のフレーミングでTLS1.3のハンドシェイクを統合し、暗号化とトランスポートの交渉を一体化しています^*2。従来のTCP+TLSでは接続確立とTLS交渉を別々のラウンドトリップで行っていましたが、QUICではこの往復を短縮できる構造になっています^*2*3。

0-RTTによる再接続の高速化

以前に接続したサーバーに再接続する際、QUICはハンドシェイク完了を待たずにアプリケーションデータを送信できる0-RTTという仕組みを備えています^*2。ただしRFC 9000は、0-RTTで送られたデータにはリプレイ攻撃への保護が及ばない点を明記しており、冪等性のない処理を0-RTTのデータで実行しないよう注意を求めています^*2。外注先に0-RTTの有効化を依頼する際は、対象エンドポイントの冪等性についても確認事項に含めておくとよいでしょう。

対応の実務——CDN・サーバーの設定とAlt-Svcによる告知

自社でHTTP/3対応を進める場合、まず確認するのはCDNやロードバランサ側の対応状況です。AWSは2022年8月15日、Amazon CloudFrontの全エッジロケーションでHTTP/3対応を発表しました^*6。設定はコンソールの配信設定で「Supported HTTP versions」にHTTP/3を追加するか、UpdateDistribution APIから変更でき、追加費用は発生しません^*6。

Google Cloudも2021年6月23日、Cloud CDNとHTTPS Load BalancingでのHTTP/3対応を発表しています^*7。有効化はConsoleまたはgcloudコマンドから行えるとされ、発表当時は数週間以内に既存ユーザーへも順次デフォルト有効化する計画が示されていました^*7。いずれのサービスも、既存のHTTP/1.1・HTTP/2利用者に影響を与えずに段階導入できる点が共通しています。

この段階導入を支えるのがAlt-Svcヘッダーです。サーバーは既存の接続には影響を与えずに、Alt-Svc: h3=”:443″; ma=86400のような形式でHTTP/3エンドポイントの存在をクライアントへ通知します^*1*5。クライアントはこのヘッダーを受け取った次回以降の接続で、HTTP/3への接続を試すという流れになります^*5。オリジンサーバー側で自前にHTTP/3を実装する場合は、TLS1.3証明書の準備とQUIC対応のWebサーバーソフトウェアの選定も合わせて必要です。

移行の落とし穴と効果測定——フォールバックとCore Web Vitals

UDPは企業ネットワークのファイアウォールやプロキシで通過を制限されている場合があります。この場合クライアントはHTTP/3への接続に失敗し、HTTP/1.1やHTTP/2へ自動的にフォールバックする必要があります。AWSもCloudFrontの解説で、ユーザーがHTTP/3接続に失敗した際にHTTP/1.1またはHTTP/2へ自動的にフォールバックする仕組みを備えていると説明しています^*6。有効化する側は、フォールバック時の挙動もあわせて検証しておくことが実務上の要点になります。

効果測定では、TTFB(Time to First Byte)の変化がわかりやすい指標です。web.devはTTFB自体はCore Web Vitalsの指標ではないとしつつ、TTFBの値が大きいとLCPなど後続の指標にも時間が積み重なっていくと説明しています^*8。CDN事業者がHTTP/2やHTTP/3のような新しい世代のプロトコルでエッジサーバーからコンテンツを配信すること自体が、TTFB短縮の一因になり得るとも述べられています^*8。

実測値としては、AWSがCloudFrontの利用企業の事例で、HTTP/3の有効化後にTTFBが10%程度まで改善したという報告を紹介しています^*6。Google Cloudは自社サービスでの展開結果として、検索のレイテンシーを2%削減、YouTubeの再バッファ時間を9%削減、モバイル回線でのスループットを7%向上させたと公表しています^*7。これらはいずれも各社固有の環境での数値であり、自社サイトで同等の改善が出るとは限らないため、有効化の前後でTTFBや実ユーザー計測(RUM)の値を比較する運用が現実的です。

内製と外注の分かれ目——対応体制で判断する

CDN側のHTTP/3対応をコンソールで有効にするだけであれば、内製での対応も難しくありません。判断が分かれるのは、複数のCDN・オンプレミスのロードバランサ・自前のWebサーバーが混在する構成や、UDP遮断によるフォールバック挙動の検証、TLS1.3証明書の運用体制まで含めて見直す場合です。

外注を検討する際は、現状構成の調査から有効化後の挙動確認、社内ネットワークやモバイル回線でのフォールバック検証、効果測定までを一括して依頼できるかを確認します。委託先が元請（プライムベンダー）として上流の調査から下流の検証まで一貫して対応できる体制かどうかも、選定の判断材料になります。

まとめ：HTTP/3・QUIC対応で押さえる3つの判断軸

本稿ではHTTP/3・QUICの仕組みと対応の実務を、IETFやAWS・Google Cloudの公式情報をもとに整理しました。要点は3つに集約できます。第一に、HTTP/3はQUIC(RFC 9000)というUDPベースのトランスポート層を土台にした規格で、ストリーム単位の独立した損失処理によってヘッドオブラインブロッキングを解消しています^*1*2。第二に、対応の実務ではCDN・ロードバランサ側の有効化とAlt-Svcによる段階的な告知、UDP遮断時のフォールバック検証が欠かせません^*5*6。第三に、効果はTTFBなどの指標で確認できますが、公表されている改善幅は各社固有の環境での数値であるため、自社環境での計測を前提に内製と外注の体制を判断する必要があります^*7*8。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IETF「RFC 9114: HTTP/3」（2022年6月）（https://www.rfc-editor.org/rfc/rfc9114.html）
2. *2　出典：IETF「RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport」（2021年5月）（https://www.rfc-editor.org/rfc/rfc9000.html）
3. *3　出典：MDN Web Docs「QUIC」（Glossary）（https://developer.mozilla.org/en-US/docs/Glossary/QUIC）
4. *4　出典：MDN Web Docs「Evolution of HTTP」（https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Evolution_of_HTTP）
5. *5　出典：MDN Web Docs「Alt-Svc」（HTTP Headers Reference）（https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Alt-Svc）
6. *6　出典：AWS News Blog「New – HTTP/3 Support for Amazon CloudFront」（2022年8月15日）（https://aws.amazon.com/blogs/aws/new-http-3-support-for-amazon-cloudfront/）
7. *7　出典：Google Cloud Blog「Cloud CDN and Load Balancing support HTTP/3」（2021年6月23日）（https://cloud.google.com/blog/products/networking/cloud-cdn-and-load-balancing-support-http3）
8. *8　出典：web.dev「Optimize Time to First Byte」（https://web.dev/articles/optimize-ttfb）

Tweet