短.beHTTP/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 と同じです。ただし、初回接続時にサーバーが HTTP の Alt-Svc ヘッダーを返したり、DNS の HTTPS レコードで知らせたりすることで、後続の接続を HTTP/3 に切り替えられます。
CDN と組み合わせて HTTP/3 を使う構成もあります。 CloudFront (2022 年 8 月から)、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 段の合計時間を短くすると、利用者の待ち時間が減ります。