301 vs 302：リダイレクトの「意味論」がネットワークパフォーマンスに与える冷徹な現実
HTTP/1.1の時代から現代のHTTP/3に至るまで、リダイレクトはWebインフラにおいて最も過小評価され、かつ最も誤用されている機能の一つだ。単に「URLを転送する」という表面的な理解で済ませていると、レイテンシの増大やキャッシュポイズニング、果てはSEO資産の散逸という致命的な負債を抱えることになる。
今日は、プロトコルスペシャリストの視点から、301と302の「セマンティクス」がパケットレベルでどのような挙動を引き起こし、それがインフラのパフォーマンスとセキュリティにどう直結するのかを深掘りする。
—
1. 301 Moved Permanently：恒久の重みとTCP/TLSのオーバーヘッド
301は、ブラウザや中間キャッシュサーバー（CDN）に対し、「このリソースは二度と元の場所には戻らない」と宣言する。
パケットレベルの挙動と最適化
クライアントが301を受け取ると、ブラウザはその情報を永続的にキャッシュする。次回以降、クライアントはオリジンサーバーに到達することなく、ローカルキャッシュから新しいURLへの遷移を行う。これは、TCPの3ウェイハンドシェイクやTLSのフルハンドシェイクを完全にスキップできることを意味する。
インフラサイドの最適化ポイント:
高トラフィックな環境では、301をアプリケーションレイヤーで処理してはいけない。Nginx等のエッジサーバーで完結させ、可能な限り早い段階で `301 Moved Permanently` を返す必要がある。
Nginxでの設定例
server {
listen 443 ssl http2;
server_name old-domain.com;
# 処理をアプリケーションまで渡さず、Nginxレベルで即座に返却
# 接続コストを最小化し、TCPバッファを早期開放する
return 301 https://new-domain.com$request_uri;
}
2. 302 Found：一時的な迷いと「Method遷移」の罠
302は「今回はたまたまこちらだが、次は元のURLを叩いてくれ」という一時的な避難だ。しかし、ここで注意すべきはHTTPメソッドの挙動である。
歴史的に、多くのブラウザは302を受け取ると、元のメソッド（POSTなど）をGETに強制変換してしまう挙動（いわゆる「302 Redirect Post-to-Get」）を持つ。もしAPIエンドポイントで302を安易に使うと、クライアントのPOSTリクエストがGETにすり替わり、ペイロードの欠落やセキュリティロジックの崩壊を招く。
現代のアーキテクトが選ぶべき307/308
HTTP/1.1の仕様において、メソッドを維持したままリダイレクトしたい場合は、`307 Temporary Redirect`（一時的）または `308 Permanent Redirect`（恒久的）を使用するのが正解だ。
- 302/303: メソッドがGETに変わる可能性がある（互換性重視）
- 307/308: メソッドとボディを完全に維持する（厳密なAPI設計向け）
—
3. RTT削減とパフォーマンスのボトルネック
リダイレクトが多段（301 -> 302 -> 200）になると、RTT（Round Trip Time）は倍増する。これはモバイル回線のような不安定な環境では致命的だ。
TLSハンドシェイクの「重さ」
リダイレクト先が異なるドメインである場合、改めてDNS解決を行い、TCPコネクションを張り、TLSハンドシェイクをやり直す必要がある。これだけで数百ミリ秒のロスは避けられない。
解決策：TLS False StartとSession Resumption
インフラ側では、`TLS 1.3`の採用が必須だ。TLS 1.3はハンドシェイクのレイテンシを劇的に削減する。また、`TCP Fast Open (TFO)` を活用することで、ハンドシェイク中のデータ送受信が可能になり、リダイレクトによる体感速度の低下を緩和できる。
LinuxカーネルのTCP最適化例（sysctl.conf）
SYNパケットにデータを含めるためのTFO有効化
net.ipv4.tcp_fastopen = 3
再送時のタイムアウトを抑え、低速回線でのパケットロス耐性を上げる
net.ipv4.tcp_retries2 = 5
—
4. セキュリティ：リダイレクト攻撃とヘッダー圧縮
リダイレクトは、オープンリダイレクト脆弱性（Open Redirect）の温床でもある。攻撃者がURLパラメータを改竄し、自サイトへリダイレクトさせる手口は古典的だが今もなお脅威だ。
また、HTTP/2やHTTP/3（QUIC）ではヘッダー圧縮（HPACK/QPACK）が適用されるが、リダイレクトによって発生する大量のLocationヘッダーが適切にキャッシュされないと、圧縮効率が落ちるだけでなく、中間者攻撃（MitM）の標的になりやすい。
信頼の担保
リダイレクト先は必ずホワイトリストで管理し、`Strict-Transport-Security (HSTS)` を活用して、すべてのリダイレクトをHTTPS上で完結させること。
HSTSヘッダーでリダイレクト後の接続を強制的にセキュアにする
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
—
結びに代えて：プロトコルは「意図」を語る
301と302を単なる「転送先設定」と捉えてはいけない。それは、クライアントとサーバー間で行われる「リソースの所在に関する合意」であり、ネットワークのトラフィック制御そのものだ。
インフラアーキテクトとして、パケットがどのルートを辿り、どのハンドシェイクがどこで発生しているかを見極めること。HTTPのステータスコード一つひとつに、あなたの設計思想と「ユーザー体験に対する責任」を込めること。それが、真に強靭なネットワークを構築するための唯一の道である。
コメント