URL 短縮サービスの技術的な仕組みは、ショートコード生成、データベース保存、 HTTP リダイレクトの 3 つの要素で構成されています。この記事では、短縮 URL がどのように生成され、ユーザーを元の URL へ転送するのかを、実際の HTTP レスポンス例を交えて解説します。
まず、ユーザーが長い URL を入力すると、サービス側でユニークなショートコードを生成します。生成方法にはいくつかのアプローチがあります。ランダムな英数字列を生成する方法、元の URL のハッシュ値 (SHA-256 など) から先頭数文字を抽出する方法、連番をベース 62 エンコードする方法などです。ベース 62 エンコードとは、 0 〜 9 の数字 10 文字、 a 〜 z の小文字 26 文字、 A 〜 Z の大文字 26 文字の計 62 文字を使って数値を表現する方式です。たとえば、連番 100000 をベース 62 に変換すると "q0U" (3 文字) になります。 6 文字のコードであれば 62 の 6 乗 = 約 568 億通りの組み合わせが可能で、大規模サービスでも十分な一意性を確保できます。ハッシュ方式は同一 URL に対して常に同じコードを生成できる利点がありますが、衝突 (異なる URL が同じコードになる) への対処が必要です。連番方式は衝突が発生しませんが、コードが予測可能になるためセキュリティ上の配慮が求められます。
生成されたショートコードと元の URL の対応関係は、データベースに保存されます。一般的には NoSQL データベース (DynamoDB など) やリレーショナルデータベースが使用され、高速な読み取り性能が重視されます。短縮 URL へのアクセスは読み取り操作が大半を占めるため、キャッシュ層 (Redis 、 Memcached など) を設けてレスポンス速度を向上させるケースも多くあります。大規模サービスでは、 CloudFront などの CDN をオリジンサーバーの前段に配置し、リダイレクトレスポンス自体をエッジロケーションにキャッシュすることで、世界中のユーザーに対して数ミリ秒のレイテンシでリダイレクトを提供しています。ただし、 CDN キャッシュを使う場合は 301 リダイレクトのキャッシュ期間に注意が必要です。リンク先を変更してもキャッシュが残っていると古い URL へ転送され続けるため、 TTL (キャッシュ有効期間) の設計が重要になります。 HTTP プロトコルの入門書は Amazon でも探せます。
ユーザーが短縮 URL にアクセスすると、サーバーは HTTP リダイレクトを実行します。実際のリダイレクトレスポンスは次のような HTTP ヘッダーで構成されます。「 HTTP/1.1 301 Moved Permanently 」「 Location: https://example.com/very/long/original-page?utm_source=campaign 」「 Cache-Control: max-age=86400 」「 Content-Length: 0 」。ブラウザはこの Location ヘッダーを読み取り、指定された URL へ自動的に遷移します。リダイレクトには主に 301 (恒久的リダイレクト) と 302 (一時的リダイレクト) の 2 種類があります。 301 リダイレクトはブラウザにキャッシュされるため高速ですが、 2 回目以降のアクセスがサーバーを経由しなくなるため、アクセス解析の精度が下がります。 302 リダイレクトは毎回サーバーを経由するため、正確なトラッキングが可能です。多くの短縮 URL サービスがトラッキング精度を優先して 302 を採用しています。
ターミナルで curl コマンドを使えば、リダイレクトの動作を直接確認できます。「 curl -v -L https://short.url/abc 」を実行すると、レスポンスヘッダーに HTTP ステータスコードと Location ヘッダーが表示され、ブラウザがこの Location ヘッダーに従って遷移する様子を観察できます。「-I 」オプションを使えばヘッダーのみを取得でき、リダイレクトチェーンの確認に便利です。
DNS 解決からリダイレクト完了までの流れは次のとおりです。ブラウザが短縮 URL のドメインを DNS で解決し、サーバーの IP アドレスを取得します (通常 10 〜 50 ミリ秒) 。次に TLS ハンドシェイクを経て HTTPS 接続を確立し (50 〜 100 ミリ秒) 、サーバーへ HTTP GET リクエストを送信します。サーバーがショートコードをデータベースまたはキャッシュで検索して元の URL を取得し (1 〜 10 ミリ秒) 、 Location ヘッダーに元の URL を設定したリダイレクトレスポンスを返します。ブラウザが元の URL へ遷移し、同様の DNS 解決と接続確立を経てページを表示します。 CDN を利用している場合、最初の DNS 解決からリダイレクトレスポンスの受信までは 20 〜 50 ミリ秒程度で完了します。
リダイレクト方式の選択は、用途に応じたトレードオフです。 SEO を重視する恒久的なリンクには 301 が適しており、 Google はリンクジュース (SEO 評価) を 301 経由で引き継ぐことを公式に認めています。一方、クリック計測の正確性を重視するマーケティング用途には 302 が適しています。一部のサービスでは、ユーザーがリダイレクトタイプを選択できるオプションも提供されています。
関連書籍: Web 技術や HTTP の仕組みについて体系的に学びたい方には、関連書籍は Amazon で探せます。