HTTP/1.1の「Connection: keep-alive」を再考する：RTTの呪縛とTCPスタックの深淵
ネットワークアーキテクトとして多くの現場を渡り歩いてきたが、未だにHTTP/1.1の挙動を「単なるおまじない」程度に捉えているエンジニアに出会うことがある。しかし、現代のWebインフラにおいて、TCPコネクションのライフサイクル管理を疎かにすることは、パフォーマンスの死を意味する。
今回は、HTTP/1.1の生命線である`Connection: keep-alive`の本質を、パケットレベルの挙動とカーネルパラメータの最適化という観点から紐解いていきたい。
1. RTTの呪縛：なぜKeep-Aliveが不可欠なのか
HTTP/1.0の時代、リクエストごとにTCPの3ウェイ・ハンドシェイク（SYN, SYN/ACK, ACK）を繰り返すことは、まさに「通信の刑務所」に閉じ込められるようなものだった。クライアントとサーバー間のRTT（Round Trip Time）が仮に50msだとしても、TLSを組み合わせればハンドシェイクだけで数往復、つまりコネクション確立に200ms以上を浪費する。
`Connection: keep-alive`がもたらす最大の恩恵は、「ウォームなTCPコネクションの再利用」にある。一度確立したコネクション上で複数のリクエストをパイプライン（あるいはシリアル）に流し込むことで、TCPの低速なスタートアップ（Slow Start）やハンドシェイクのオーバーヘッドを劇的に排除できるのだ。
2. カーネルレベルでの最適化：TCPバッファとタイムアウトの死闘
HTTP/1.1の持続的接続を有効活用する場合、最大の敵は「アイドル状態のコネクション」だ。サーバー側でタイムアウトを短く設定しすぎれば、頻繁なハンドシェイクが発生してパフォーマンスが劣化し、長すぎればファイルディスクリプタを食いつぶし、メモリを浪費する。
実務レベルでチューニングを行う際は、LinuxカーネルのTCPスタックを以下のように調整するのが定石だ。
TCP Keepaliveのプローブ間隔を短縮し、死んだ接続を早期に検知する
デフォルトの7200秒は長すぎる。実務では60秒程度が妥当
sysctl -w net.ipv4.tcp_keepalive_time=60
プローブを送信する間隔
sysctl -w net.ipv4.tcp_keepalive_intvl=10
プローブを何回失敗したらコネクションを切断するか
sysctl -w net.ipv4.tcp_keepalive_probes=3
さらに、TLSのハンドシェイクを最適化するなら、`TCP Fast Open (TFO)`の検討も欠かせない。TFOは、SYNパケットにデータを含めることで、最初のハンドシェイクでのRTTを削減する技術だが、セキュリティポリシーとの兼ね合いを慎重に見極める必要がある。
3. ヘッダーの肥大化とTCPバッファの現実
HTTP/1.1では、ヘッダーはプレーンテキストである。これが何を意味するか？CookieやUser-Agentが肥大化すると、TCPの初期輻輳ウィンドウ（initcwnd）のサイズに収まらず、パケットが分割される。
`initcwnd`をデフォルトの10から増やすことは、小さなリクエストの爆速化に直結する。
TCPの初期輻輳ウィンドウを広げ、ハンドシェイク直後の転送効率を上げる
ip route change default via 192.168.1.1 dev eth0 initcwnd 16
ただし、これを闇雲に上げるとネットワークの輻輳を誘発する。帯域幅と遅延の積（BDP: Bandwidth Delay Product）を考慮した慎重な計算が、アーキテクトには求められる。
4. セキュリティとリソース枯渇のトレードオフ
`keep-alive`は攻撃者にとっての「踏み台」にもなり得る。特に`Slowloris`のような攻撃は、開いたままのコネクションを利用してサーバーの同時接続数制限（`MaxClients`や`WorkerThreads`）を枯渇させる。
対策の肝:
- タイムアウトの多層化: アプリケーションレイヤーのタイムアウト（`KeepAliveTimeout`）を、ネットワークレイヤーのタイムアウトより厳格に設定する。
- リバースプロキシの活用: NginxやEnvoyをフロントに置き、接続の「受口」を最適化する。Nginxであれば、`keepalive_requests`を適切に設定し、1つのコネクションで処理できるリクエスト数に上限を設けることで、メモリリークや長時間占有を防ぐ。
結論：プロトコルの美学
HTTP/1.1の`keep-alive`は、決して古い技術ではない。むしろ、HTTP/2やHTTP/3（QUIC）が普及した現代においても、その背後で動いているTCPの挙動を制御できるか否かが、システムの「キレ」を決定づける。
パケットがNICを通過し、カーネルのバッファでキューイングされ、アプリケーションへと運ばれるその一瞬一瞬を想像してほしい。技術の深淵を覗くことは、単に数値をいじることではなく、ネットワークという巨大な生命体の呼吸を整える行為に他ならない。
次に設定ファイルを開くときは、ただの数値を設定するのではなく、そこを流れるパケットの行く末に思いを馳せてみてほしい。それこそが、一流のインフラアーキテクトへの第一歩だ。
コメント