HTTP/1.1の「メソッド」を再考する：プロトコルスタックの深淵と冪等性がもたらすアーキテクチャの真実
HTTP/1.1。この枯れたプロトコルを単なる「Webの通信手段」と呼ぶのは、エンジニアとしてあまりに勿体ない。TCPの3ウェイ・ハンドシェイクを終え、TLSのネゴシエーションという重厚な儀式を経て、ようやくパケットの断片がアプリケーション層に届く。その中身、すなわち「メソッド」の選択一つが、システムの整合性とパフォーマンスを決定づける。
今日は、教科書的な説明は割愛し、インフラ・アーキテクトが知るべきHTTPメソッドの「実像」を深掘りする。
—
1. メソッドのセマンティクス：ただの文字列ではない
HTTPメソッドは、サーバーに対する「意図」の宣言だ。特に重要なのが安全性（Safety）と冪等性（Idempotency）の概念である。
- 安全性（Safety）: リクエストによってサーバー側の状態が変更されないこと。
- 冪等性（Idempotency）: 同じリクエストを何度繰り返しても、サーバー側の状態が初回と変わらないこと。
なぜこれらが重要か
インフラエンジニアにとって、この定義は「リトライ戦略」の根幹をなす。例えば、ネットワークの瞬断（TCP RSTやタイムアウト）が発生した際、冪等性がないPOSTメソッドを安易にリトライすれば、二重課金や重複レコードという悪夢を招く。逆に、PUTやDELETEであれば、冪等性が保証されているため、ネットワーク層での自動リトライの閾値を積極的に調整できる。
| メソッド | 安全 | 冪等 | 用途と留意点 |
| :— | :— | :— | :— |
| GET | ○ | ○ | 状態変更不可。キャッシュの主戦場。 |
| POST | × | × | 状態変更あり。非冪等。トランザクションの起点。 |
| PUT | × | ○ | リソースの置換。対象URIが確定している場合にのみ使用。 |
| DELETE | × | ○ | リソースの削除。冪等だが、リトライ時は404を許容する設計が必要。 |
—
2. パケットレベルの最適化とアーキテクチャの勘所
HTTP/1.1のパフォーマンスを語る上で避けて通れないのが、Head-of-Line Blocking（HOLB）とTCP/TLSのチューニングだ。
RTT削減とTCPバッファのチューニング
HTTP/1.1では、同一ドメインに対してブラウザが接続数を制限するため、Keep-Aliveを有効にしてコネクションを使い回すのが定石だ。しかし、これだけでは足りない。Linuxカーネルのネットワークスタックを触る機会があるなら、以下の調整を検討してほしい。
TCPの初期ウィンドウサイズを大きくし、初回RTTでのデータ転送量を増やす
10セグメント（約14KB）まで初期ウィンドウを拡大することで立ち上がりを高速化
ip route change default via 192.168.1.1 dev eth0 initcwnd 10
SYNパケットの再送回数を調整し、ハンドシェイクのタイムアウトを最適化
sysctl -w net.ipv4.tcp_syn_retries=3
また、TLS 1.3が普及した現在、`0-RTT`を利用すればRTTを大幅に削減できるが、これには「リプレイ攻撃」のリスクが伴う。GETであればまだしも、POSTを0-RTTで送る際は、アプリケーション層でトークン検証を行うなどのガードレールが必須となる。
—
3. OPTIONSとTRACE：脆弱性の温床を見極める
セキュリティ専門家が最も注視すべきは、あまり使われないメソッドの挙動だ。
OPTIONSメソッドの罠
`OPTIONS`はCORS（Cross-Origin Resource Sharing）のプリフライトリクエストで頻繁に使われる。この時、不要なヘッダーやメソッドを許可していないか？ `Access-Control-Allow-Methods` を厳密に制御せず、ワイルドカードで公開することは、攻撃者に内部APIの全容を教えるのと同じだ。
TRACEメソッドの排除
`TRACE`メソッドはサーバーが受け取ったリクエスト内容をそのままレスポンスとして返す。これはデバッグには便利だが、Cross-Site Tracing (XST) 攻撃の踏み台にされるリスクがある。
Nginxでの対策設定例:
不要なメソッドを拒否し、TRACEを無効化する
if ($request_method !~ ^(GET|POST|PUT|DELETE|OPTIONS)$ ) {
return 405; # メソッド不許可
}
TRACEメソッドを明示的に遮断
if ($request_method = TRACE) {
return 405;
}
—
4. なぜ「HEAD」を軽視してはいけないのか
最後にもう一つ。`HEAD`メソッドを使いこなせているだろうか？
大規模なファイルダウンロードや、アセットのキャッシュ更新確認において、リクエストボディを運ぶ必要はない。`Content-Length`や`Last-Modified`のみをヘッダーで取得し、ネットワーク帯域を節約する。
特に、CDNとの組み合わせにおいて、`HEAD`を適切に活用することは、オリジンサーバーの負荷を劇的に下げる。キャッシュのパージ戦略においても、このメソッドが最も効率的なプローブとなる。
—
結びに代えて
HTTP/1.1は古く、不完全かもしれない。しかし、その上で動くプロトコルスタックの制御、つまりTCPウィンドウの拡大から、メソッドごとの冪等性の厳密なハンドリング、そしてセキュリティリスクの排除に至るまで、我々が介入できる余地は無限にある。
「なんとなく動く」から「意図して制御する」へ。ネットワークアーキテクトとして、パケットの挙動を解像度高く捉え、堅牢かつ高速なインフラを設計し続けてほしい。このプロトコルの深淵には、まだまだ知るべき真実が埋まっているのだから。
コメント