HTTP/3 は QUIC をトランスポート層に採用した HTTP の最新版で、 2022 年に RFC 9114 として標準化、 2024 年時点で世界の上位 1 万サイトの約 35% が対応済みです。 Cloudflare の集計では、 2024 年の HTTP/3 トラフィック比率は全体の 31% に到達しました。短縮 URL のリダイレクト体験は HTTP のバージョンによって体感速度が変わるため、 HTTP/3 対応は短縮 URL サービスの競争力に直結する論点です。
HTTP/3 が短縮 URL で効くのは、初回接続のハンドシェイク時間です。 HTTP/2 までは TCP + TLS で 3 〜 4 RTT (ラウンドトリップ) が必要だったのに対し、 HTTP/3 は QUIC の 0-RTT 接続で 1 RTT 以下に短縮できます。短縮 URL のクリックでは、 DNS 解決、 TLS ハンドシェイク、 HTTP リクエスト、リダイレクト応答の往復、リダイレクト先への再接続、と複数の往復が発生します。 HTTP/3 を採用すると、特にモバイル回線でのリダイレクト体感速度が 100 ms 〜 300 ms 改善する例があります。
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 のリダイレクトデータをエッジ KV ストア ( Cloudflare Workers KV、 CloudFront Functions の組み込みキャッシュ) に持つと、世界中のエッジから 1 ミリ秒以下のレイテンシで応答できます。
0-RTT の活用には注意点があります。 0-RTT は再接続時の往復削減に有効ですが、リプレイ攻撃のリスクがあるため、リダイレクト処理のような副作用のない GET 要求にしか適用できません。 POST 要求や状態を変える操作には適用しないのが標準です。短縮 URL のリダイレクトは GET 要求の副作用なし操作 (ログ書き込みは非同期) に該当するため、 0-RTT 適用の好条件です。 Web 技術の体系を学ぶには、関連書籍は Amazon でも探せます。
HTTP/3 の運用面で見落とされがちなのが、 UDP のフィルタリング問題です。一部の企業 LAN や旧式のファイアウォールは UDP 443 をブロックしており、その環境では HTTP/3 接続が確立できず TCP の HTTP/2 にフォールバックします。フォールバックの判定は数百ミリ秒かかるため、初回接続の遅延体感がむしろ悪化する逆説が起こります。 Alt-Svc の 「persist=1」 や DNS の HTTPS レコードで HTTP/3 対応を事前にクライアントに伝える構成にすると、フォールバック時の遅延を抑えられます。
HTTP/3 と短縮 URL の組み合わせは、モバイル UX、 SEO のページ速度評価、 CDN との親和性のすべてに効きます。リダイレクト 1 段の合計時間を 100 ms 以下に抑える運用ができると、検索流入の離脱率と SEO 評価の両方が改善します。