帯域の無駄を削ぎ落とせ：HTTP/1.1 `Expect: 100-continue` が語るプロトコルの美学
ネットワークエンジニアとして現場に立つとき、我々は常に「RTT（Round Trip Time）との戦い」を強いられる。特に巨大なファイルをアップロードする際、クライアントが何も考えずに数メガバイトのペイロードを投げ込み、サーバー側の認証エラーやポリシー違反でその全てが「ゴミ」として破棄される光景を目にしたことはないだろうか。
現代のインフラ設計において、帯域とリソースは有限だ。HTTP/1.1が持つ `Expect: 100-continue` という小さな仕組みは、一見すると地味なフローに見えるが、実は「無駄なパケットを流さない」というプロトコル設計の極致を示している。今回は、この挙動をパケットレベルから解剖し、高負荷環境における最適解を導き出そう。
—
1. 100-continueのパケットフロー：その「間」の真実
`Expect: 100-continue` の真価は、リクエストヘッダーとボディの間に「検証のゲート」を設ける点にある。一般的なリクエストがヘッダーとボディを一体として送信するのに対し、この仕組みは以下の挙動をとる。
1. クライアント: `Expect: 100-continue` を含むヘッダーのみを送信し、一旦待機する。
2. サーバー: リクエストの妥当性（認証、許可、容量制限など）を判断する。
3. サーバー: 許可する場合、`HTTP/1.1 100 Continue` を即座に返す。
4. クライアント: 100レスポンスを受け取った瞬間に、ボディの送信を開始する。
この「待ち時間」は、一見するとRTTを増やすように見えるかもしれない。しかし、不正なリクエストに対して数十メガバイトのデータをTCPウィンドウに流し込むコストと比較すれば、この「一往復の会話」は圧倒的に経済的なのだ。
—
2. インフラアーキテクトが知るべきトランスポート層の罠
この挙動を支えるのは、TCPの輻輳制御とTLSのオーバーヘッドだ。特に注意すべきは、「タイマーの実装」である。
多くのクライアント実装（例えば `curl` や各種言語のHTTPライブラリ）は、100レスポンスを待つ時間をデフォルトで 1秒〜2秒程度に設定している。もしサーバー側のバックエンドが重く、レスポンスが遅延すると、クライアントは「サーバーは待てない」と判断し、レスポンスを待たずにボディ送信を開始してしまう。
調整すべきカーネルパラメーター (Linux)
サーバーサイドで大量のリクエストを捌く場合、TCPバッファの管理が鍵となる。`tcp_rmem` や `tcp_wmem` の最適化はもちろん重要だが、`Expect` のフローが頻発する環境では、以下のチューニングが効いてくる。
クライアントからの大量接続を想定し、FIN_WAITの時間を短縮してメモリを解放
sysctl -w net.ipv4.tcp_fin_timeout=15
再送制御の最適化：100-continueの「間」で発生するパケットロスを早めに検知
sysctl -w net.ipv4.tcp_retries2=5
—
3. セキュリティとパフォーマンスのトレードオフ
セキュリティ専門家の視点から見れば、`Expect: 100-continue` はDDoS対策の第一線になり得る。巨大なリクエストボディを送りつけてサーバーのメモリを枯渇させるタイプの攻撃に対し、ヘッダー段階で「拒絶（417 Expectation Failed または 401 Unauthorized）」を突きつけることができるからだ。
しかし、ここで忘れてはならないのが TLSハンドシェイクとの相性 である。TLS 1.3であれば、0-RTTデータを利用してヘッダーとボディを同時に投げ込むことが可能だが、`Expect: 100-continue` を強制すると、せっかくの0-RTTが活きない。
実践的な推奨設定 (Nginx)
Nginxでこの挙動を制御する場合、`client_body_buffer_size` との兼ね合いが重要だ。
巨大なリクエストに対する防御とパフォーマンスのバランス
client_max_body_size 10M; # 許容する最大容量を明示的に制限
client_body_buffer_size 128k; # メモリ上で処理可能なバッファサイズ
サーバー側でExpectヘッダーをどう扱うか
0はクライアントに100-continueを返さない設定（特殊な環境用）
1は標準的な振る舞い
proxy_http_version 1.1;
proxy_set_header Expect “100-continue”;
—
4. 結び：プロトコルの「行間」を読み解く力
HTTP/1.1は古臭い規格だと言われることもある。しかし、HTTP/2やHTTP/3が普及した現在においても、この `Expect: 100-continue` のような「サーバーとクライアントの合意形成」という考え方は、マイクロサービス間通信やAPIゲートウェイ設計において極めて強力な武器だ。
単に動くコードを書くのではなく、ネットワークの「裏側」で何が起きているのか。パケットがTCPウィンドウの中でどう踊り、TLSの暗号化の裏でどのようなステートマシンが遷移しているのか。その深淵にまで思いを馳せることこそが、我々エンジニアが持つべき「アーキテクトの矜持」である。
次回のデバッグ時には、ぜひ `tcpdump` を片手に、この100レスポンスの「溜め」を観測してみてほしい。そこには、数ミリ秒を削り出し、システム全体を堅牢にするためのプロトコルの知恵が詰まっているのだから。
コメント