HTTP 408 Request Timeout：その「沈黙」が語るトランスポート層の深淵
ネットワークエンジニアとして現場に立つとき、私たちはしばしば「408 Request Timeout」というステータスコードを、単なる「遅延」の副産物として片付けてしまいがちだ。しかし、このコードがサーバーから送出される瞬間、バックエンドでは一体何が起きているのか。それはTCPコネクションの死の宣告であり、同時にアプリケーション層がトランスポート層の制約に屈した瞬間の記録でもある。
今日は、HTTP/1.1の時代から現代のハイパフォーマンス環境に至るまで、この「408」が突きつける本質的な問題について、パケットレベルの挙動からカーネルチューニングの勘所までを解剖していこう。
—
1. 408はなぜ発生するのか：サーバー側の「待機」というコスト
HTTP 408 Request Timeoutは、サーバーが「リクエスト全体の到着を待ちきれなくなった」時に発せられる。これはTCPの接続（ハンドシェイク）が完了した後、サーバーが受信バッファを確保し、`read()` システムコールを発行してデータ待ちの状態に入ったものの、設定されたタイムアウト期間内にHTTPリクエストメッセージが完結しなかったことを意味する。
ここで重要なのは、「サーバーはクライアントが送信を開始したこと自体は知っているが、完結する前に諦めた」という点だ。
サーバー側の内部挙動
NginxなどのWebサーバーでは、`client_body_timeout` や `keepalive_timeout` がこのトリガーとなる。
- TCPのウィンドウ制御: クライアント側のネットワークが不安定で、パケットロスによりTCP再送が発生し、セグメントの到着が遅延する。
- Slowloris攻撃の予兆: 悪意のあるクライアントが、ヘッダーを極端に小出しにして送信し、サーバーのリソースを占有しようとする。
サーバーは、タイムアウトを検知すると `RST` パケットを投げるか、正常にステータスコード `408` を書き込んだレスポンスを返して `FIN` を送り、コネクションをクローズする。セキュリティの観点から言えば、このタイムアウト設定を適切に行うことは、DoS攻撃に対する最低限の防波堤となる。
—
2. トランスポート層の最適化：RTTとTCPバッファ
408エラーの頻発は、往々にしてインフラ側のチューニング不足を露呈させる。特に、RTT（Round Trip Time）が大きい環境では、TCPの初期ウィンドウサイズ（`initcwnd`）がボトルネックとなる。
Linuxカーネルレベルでこの挙動を最適化するには、まずTCPバッファの動的調整を検討すべきだ。
sysctl.conf でのTCPバッファチューニング例
送受信バッファの最小値、デフォルト値、最大値を設定
net.ipv4.tcp_rmem = 4096 87380 6291456
net.ipv4.tcp_wmem = 4096 16384 4194304
TCP Fast Openを有効化し、3ウェイハンドシェイクのRTTを削減
net.ipv4.tcp_fastopen = 3
`TCP Fast Open` を有効にすることで、ハンドシェイク中のデータ転送が可能になり、初回のリクエスト到着までのRTTを1往復分削ることができる。これが408を回避するための「最初の一手」となる。
—
3. TLSハンドシェイクとHTTP/1.1の呪縛
HTTP/1.1では、`Keep-Alive` が有効な場合、コネクションを再利用する。しかし、TLSハンドシェイクが重い場合、最初の1バイトが届くまでの「沈黙」が長引き、サーバー側のタイマーを枯渇させることがある。
ここでアーキテクトが意識すべきは、「TLSセッション再開（Session Resumption）」の活用だ。
- TLS Session IDs / Session Tickets: 以前のセッション情報を再利用することで、ハンドシェイクを短縮する。
- OCSP Stapling: クライアントが証明書失効確認のためにCAへアクセスする時間を削減し、サーバー側でレスポンスを完結させる。
これらを行うことで、HTTPリクエストがアプリケーション層に到達するまでの物理的な時間を物理限界まで短縮し、結果として408の発生確率を下げる。
—
4. 現場でのデバッグ：パケットを「可視化」する
もし、特定のクライアントからのリクエストで408が多発しているなら、`tcpdump` でパケットのシーケンスを追うのが最も確実だ。
特定のクライアントIPからのHTTP通信を追跡し、パケット間の到着間隔を可視化
tcpdump -ni eth0 host <クライアントIP> and port 443 -vv -t -e
注目すべきは、「PUSHフラグが立っているパケットがどの間隔で到着しているか」だ。もしパケット間隔が `client_body_timeout` に近づいているなら、それはネットワークの問題ではなく、クライアント側のアプリケーションの送信ロジック（小出しのヘッダー送信など）に問題がある可能性が高い。
—
結論：408は「最適化」への招待状である
HTTP 408 Request Timeoutは、単なるエラーではない。それは、あなたのサーバーがトランスポート層の遅延という「現実」に直面した時の悲鳴である。
インフラを司る我々は、単にタイムアウト時間を延長してエラーを隠蔽するのではなく、TCPのウィンドウ制御、TLSのハンドシェイク最適化、そして適切なタイムアウト設計を組み合わせ、パケットが最短距離でサーバーのアプリケーションロジックへ到達できる経路を構築しなければならない。
次のデプロイでは、ぜひカーネルパラメータとパケットのシーケンスを今一度見直してほしい。その「沈黙」を解消したとき、あなたのサービスは、より強固で、より軽快なパフォーマンスを手に入れるはずだ。
コメント