HTTP/3 は QUIC をトランスポート層に採用した HTTP のバージョンで、 2022 年に RFC 9114 として標準化されました。主要なブラウザと CDN が対応済みで、実際に流れるリクエストのうち一定の割合が HTTP/3 でやり取りされています。短縮 URL のリダイレクト体験は HTTP のバージョンによって体感速度が変わるため、 HTTP/3 対応は短縮 URL サービスの競争力に直結する論点です。
HTTP/3 が短縮 URL で効くのは、初回接続のハンドシェイク時間です。 HTTP/2 までは TCP の接続確立と TLS のハンドシェイクが別々に走るため、データを送り始めるまでに複数の往復 (ラウンドトリップ) がかかります。 HTTP/3 では QUIC がトランスポートと暗号のハンドシェイクを一体化しているので初回接続は 1 往復で済み、一度つないだ相手への再接続では 0-RTT でデータを送り始められます。短縮 URL のクリックでは、 DNS 解決、 TLS ハンドシェイク、 HTTP リクエスト、リダイレクト応答の往復、リダイレクト先への再接続、と複数の往復が発生します。 HTTP/3 を採用するとハンドシェイクの往復回数が減るため初回接続のレイテンシが下がり、遅延やパケットロスの大きいモバイル回線ほどリダイレクトの体感速度改善が出やすくなります。
3xx レスポンスの扱いは HTTP/3 でも基本的に変わりません。 301 (恒久的移動)、 302 (一時的移動)、 307 (一時、メソッド保持)、 308 (恒久、メソッド保持) のセマンティクスは HTTP/2 と同じです。ただし、 QUIC の特性として、初回接続時にサーバーが Alt-Svc ヘッダーや HTTPS DNS レコードを返すことで、後続の接続を HTTP/3 に切り替えられるため、 301 リダイレクトを返すサーバー側で Alt-Svc を併送すると、リダイレクト先サーバーへの接続が HTTP/3 でできる可能性が高まります。
CDN との組み合わせは HTTP/3 の効果を最大化する鍵です。 CloudFront、 Cloudflare、 Fastly はいずれも HTTP/3 を標準サポートしており、エッジロケーションでリダイレクト処理を完結させると、オリジンへの往復なしで応答できます。短縮 URL のリダイレクトデータをエッジ側に分散配置されるデータストア ( Cloudflare Workers KV など) に持たせると、世界中のエッジがオリジンへ問い合わせずに応答を組み立てられます。
0-RTT の活用には注意点があります。 0-RTT は再接続時の往復削減に有効ですが、リプレイ攻撃のリスクがあるため、リダイレクト処理のような副作用のない GET 要求にしか適用できません。 POST 要求や状態を変える操作には適用しないのが標準です。短縮 URL のリダイレクトは GET 要求の副作用なし操作 (ログ書き込みは非同期) に該当するため、 0-RTT 適用の好条件です。
HTTP/3 の運用面で見落とされがちなのが、 UDP のフィルタリング問題です。一部の企業 LAN や旧式のファイアウォールは UDP 443 をブロックしており、その環境では HTTP/3 接続が確立できず TCP の HTTP/2 にフォールバックします。フォールバックの判定は数百ミリ秒かかるため、初回接続の遅延体感がむしろ悪化する逆説が起こります。 DNS の HTTPS レコードで HTTP/3 対応をあらかじめクライアントに伝え、 Alt-Svc には persist=1 を添えてネットワークが切り替わっても代替サービスの情報を保持させる構成にすると、フォールバック時の遅延を抑えられます。
HTTP/3 と短縮 URL の組み合わせは、モバイル UX、 SEO のページ速度評価、 CDN との親和性のすべてに効きます。リダイレクト 1 段の合計時間を 100 ms 以下に抑えられれば、待たされた末の離脱を減らせますし、ページ表示速度を評価する検索エンジンの指標にも有利に働きます。