HTTP OPTIONSとCORSの深淵：インフラ視点で紐解く「見えない通信」の最適化
Webエンジニアであれば誰しも一度はブラウザのデベロッパーツールで、不可解な「OPTIONS」リクエストを目にしたことがあるだろう。多くはCORS（Cross-Origin Resource Sharing）のプリフライトとして現れるこのメソッドだが、単なる「おまじない」として済ませていないだろうか？
我々インフラアーキテクトにとって、このOPTIONSメソッドは単なるプロトコルの一部ではない。ネットワークのレイテンシ、TLSハンドシェイクのオーバーヘッド、そしてサーバーのI/Oコストが複雑に絡み合う「最適化の最前線」である。
OPTIONSメソッドの本来の姿とCORSの変容
HTTP/1.1の仕様（RFC 7231）において、OPTIONSメソッドは「リクエスト対象のリソースに対して、サーバーがサポートしている通信オプションを問い合わせる」ためのものだ。しかし、現代のWebにおいてこのメソッドは、CORSというセキュリティ機構の「門番」としてその役割を大きく変えた。
ブラウザは、クロスオリジンなリクエストが発生する際、本番のリクエスト（POSTやPATCHなど）を投げる前に、サーバーがその要求を受け入れる権限を持っているかを「プリフライト」として確認する。このとき発生するOPTIONSリクエストは、インフラ設計において無視できないコストとなる。
パケットレベルで見る「RTTの無駄」とパフォーマンスへの影響
プリフライトリクエストは、単体では小さなペイロードだが、ネットワークの物理的な距離とトランスポート層の特性が加わると、無視できない遅延を生む。
1. TCP/TLSハンドシェイクの再利用: Keep-Aliveが無効、あるいはTCP接続が切断されている場合、OPTIONSのために再度3-way handshakeとTLSネゴシエーションが走る。これはモバイル環境などRTTが長い環境では、致命的なユーザー体験の低下を招く。
2. TCPバッファとスロースタート: プリフライトが頻発すると、TCPの初期ウィンドウサイズが使い切られず、常にスロースタートの制約を受ける。これにより、続く本番リクエストの立ち上がりが鈍化する。
最適化の解：`Access-Control-Max-Age` の重要性
インフラ担当者がまず着手すべきは、`Access-Control-Max-Age` ヘッダーによるプリフライト結果のキャッシュ戦略だ。
Nginx設定例: プリフライト結果を24時間キャッシュさせる
location /api/ {
# プリフライトリクエスト(OPTIONS)に対するレスポンス制御
if ($request_method = ‘OPTIONS’) {
add_header ‘Access-Control-Allow-Origin’ ‘https://app.example.com’;
add_header ‘Access-Control-Allow-Methods’ ‘GET, POST, OPTIONS’;
add_header ‘Access-Control-Allow-Headers’ ‘DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization’;
# ここが重要：クライアント側のブラウザにプリフライト結果をキャッシュさせる秒数
# 86400秒（24時間）設定することで、同一セッション内の余計なOPTIONS通信を排除する
add_header ‘Access-Control-Max-Age’ 86400;
add_header ‘Content-Type’ ‘text/plain; charset=utf-8’;
add_header ‘Content-Length’ 0;
return 204; # 本文なしで即座にハンドシェイクを終了させる
}
}
セキュリティとパフォーマンスのトレードオフ：脆弱性を回避する
OPTIONSメソッドを安易に許可することは、攻撃者にサーバーのAPI構造を露呈させるリスクがある。特に、`Access-Control-Allow-Origin` をワイルドカード（“）に設定するのは、認証情報が必要なリクエストにおいてはセキュリティホールとなる。
ネットワークアーキテクトが意識すべき3つのポイント
1. TLS False Startの活用:
TLS 1.2/1.3において、ハンドシェイクの完了を待たずにアプリケーションデータを送信する「False Start」を有効にすることで、プリフライトの体感待ち時間を削減できる。OpenSSLやカーネルパラメータで調整可能だ。
2. HTTP/2・HTTP/3の多重化:
HTTP/1.1では「1コネクション1リクエスト」の制約が厳しいが、HTTP/2以降はストリームの多重化により、プリフライトのオーバーヘッドを大幅に抑制できる。インフラ層でALPN（Application-Layer Protocol Negotiation）を適切に構成することが、現代のパフォーマンスチューニングの鉄則だ。
3. 不必要なOPTIONSを遮断:
アプリケーションが不要なメソッドをすべて受け入れる設定は避けるべきだ。Nginx等のリバースプロキシ層で、許可されたエンドポイント以外へのOPTIONSメソッドを405 (Method Not Allowed) で弾く構成を徹底しよう。
結びに代えて：プロトコルと真摯に向き合うということ
「OPTIONSメソッドが遅いからCORSをやめる」といった安易な選択は、Webのオープン性を損なう。私たちがやるべきは、プロトコルの仕様を深く理解し、TCPスタックの挙動やTLSのハンドシェイクコストを勘案した上で、最も効率的なレスポンスを返すアーキテクチャを設計することだ。
パケットの一つひとつに意志が宿っていると信じ、その流れを滞らせないのが我々ネットワークスペシャリストの矜持である。プリフライトリクエストを単なる障害と捉えず、インフラの健全性を測るための重要なシグナルとして活用してほしい。
コメント