Keep-Aliveの呪縛と解放：TCPの「細道」を極限まで太くするHTTP/1.1持続的接続の深層
ネットワークエンジニアなら誰もが知っているはずだ。ブラウザがWebページを読み込む際、画面の向こう側で何本ものTCPセグメントが激しく交錯している光景を。
だが、ちょっと待ってほしい。HTTP/1.0の時代、ブラウザはテキストフッターを1つ取得するたびに、わざわざ3WayハンドシェイクでTCPコネクションを確立し、データを引き剥がし、そして容赦なく`FIN`パケットを投げて破棄していた。
「1つのリクエストごとに家を建て直しては壊すようなものだ」――そう例えられる非効率な非持続的接続の闇から私たちを救い出したのが、HTTP/1.1で標準化された `Connection: keep-alive` である。
今回は、このあまりにも身近でありながら、LinuxカーネルのチューニングやTLSハンドシェイクの最適化、さらには高度なセキュリティの文脈において今なおエンジニアの頭を悩ませる「持続的接続（Persistent Connection）」の本質を、パケットレベルの挙動から徹底的に解剖していこう。
—
1. パケットが語る真実：3WayハンドシェイクとTLSネゴシエーションのコスト
まず、トランスポート層の物理的現実を直視しよう。クライアントがオリジンサーバーと通信を開始するとき、レイヤー4のTCPでは必ずあの「SYN, SYN-ACK, ACK」の3Wayハンドシェイクが発生する。もしHTTPSであれば、その上にさらにTLS 1.2（あるいは1.3）の暗号化ネゴシエーションが覆いかぶさる。
地球の裏側にあるサーバーと通信する場合、物理的な伝播遅延（Propagation Delay）だけで数十ミリ秒から百数十ミリ秒のRTT（Round Trip Time）が消費される。
[Client] [Server]
|—- (1) TCP SYN ——————————–>| <-- RTT 1回目
|<--- (2) TCP SYN-ACK -----------------------------|
|---- (3) TCP ACK (+ TLS Client Hello) ----------->| <-- RTT 2回目 (TLS 1.3ならここで完了も)
|<--- (4) TLS Server Hello + Certificate ----------|
|---- (5) HTTP GET /index.html ------------------->| <-- 実際のデータ転送開始
HTTP/1.0では、画像やCSS、JavaScriptを読み込むたびにこの儀式が繰り返されていた。
しかし、`Connection: keep-alive`（HTTP/1.1ではデフォルトで有効）が存在していれば、一度確立したTCPコネクションは閉じられず、パイプライン化あるいは連続したリクエストのトランスポートとして再利用（Connection Reuse）される。これにより、2回目以降のリクエストにおいてハンドシェイクのオーバーヘッドが完全にゼロになる。この恩恵は、ミリ秒単位のレイテンシを削り出す現場において、何物にも代えがたい武器となる。
---
2. タイムアウトのジレンマ：Keep-Alive TimeoutとMax Requestsの攻防
無限にコネクションを維持できれば理想的か？ 答えは「NO」だ。インフラアーキテクトが夜も眠れなくなる原因の一つが、この持続的接続の「保持コスト」である。
サーバー側のメモリ上には、アクティブなTCPコネクションごとにソケットバッファ（送受信キュー）が割り当てられる。もし悪意あるクライアントや、異常終了したクライアントがコネクションを掴んだまま放置したらどうなるか？ サーバーのリソース（ファイルディスクリプタやメモリ）は瞬く間に枯渇し、いわゆる資源枯渇型DoS攻撃の格好の標的となる。
これを防ぐために存在するのが、`Keep-Alive Timeout` と `Max Requests`（最大リクエスト数）のパラメータだ。NginxやApache HTTP Serverの現場設定を覗いてみよう。
Nginxにおける実用的なKeep-Aliveチューニング例
http {
# クライアントとの持続的接続のタイムアウト時間を設定
# 長すぎるとゾンビコネクションでリソースが圧迫され、短すぎると再接続コストが増える
keepalive_timeout 65s;
# 1つのKeep-Aliveコネクション経由で処理できる最大リクエスト数
# これを超えるリクエストが来たら、サーバー側からコネクションを切断し、メモリリークやリソース偏重を防ぐ
keepalive_requests 1000;
# アップストリーム（バックエンドのアプリケーションサーバー）との接続維持設定
upstream backend_cluster {
server 10.0.1.10:8080;
server 10.0.1.11:8080;
# バックエンドとのTCPコネクションをキャッシュしておくプールのサイズ
keepalive 32;
# アップストリーム側のアイドルタイムアウト
keepalive_timeout 60s;
}
}
この絶妙なバランス調整がアーキテクトの腕の見せ所だ。タイムアウトを短くしすぎると、ブラウザが少し重い処理をしている間にコネクションが切断され、無駄な再接続が発生する。逆に長くしすぎると、C10K問題ならぬ「C10M問題」の足音が一歩近づくことになる。
—
3. パイプライン化の挫折と、HTTP/1.1が抱えた「頭の痛い問題」
HTTP/1.1には、持続的接続をさらに加速させるための機能として「HTTPパイプライン（HTTP Pipelining）」が仕様として盛り込まれた。これは、レスポンスを待たずに複数のリクエストを連続してTCPソケットに投げ込む技術だ。
しかし、実際のインターネットにおいて、パイプライン化はほぼ「封印された技術」となった。なぜか？
それが 「ヘッド・オブ・ライン・ブロッキング（HOLB: Head-of-Line Blocking）」 の悪夢である。
1. クライアントがリクエストAとリクエストBをこの順で同じコネクションに流し込んだ。
2. サーバー側で、リクエストAの処理に想定以上の時間がかかり、リクエストBの処理は一瞬で終わった。
3. しかし、HTTP/1.1のプロトコル仕様上、レスポンスはリクエストの順序通りに返さなければならない。
4. 結果として、リクエストBのレスポンスは、リクエストAの処理が完了するまでソケットの手前で足止めを食らうことになる。
このトランスポート層およびアプリケーション層における直列化の呪縛を根本から打ち破るために登場したのが、HTTP/2の「ストリーム多重化」である。しかし、HTTP/1.1というレガシーかつ巨大なインフラ基盤の上で生き残る私たちにとって、`Connection: keep-alive` は依然としてパフォーマンスの生命線であり続けている。
—
4. セキュリティとインフラの現場：HTTP Request Smugglingの脅威
持続的接続を語る上で、セキュリティの観点を外すことはプロフェッショナルとしてあり得ない。ここで取り上げるのが 「HTTPリクエストスマグリング（HTTP Request Smuggling）」 だ。
現代のWebアーキテクチャは、フロントエンドにリバースプロキシ（Nginx, Varnish, AWS ALBなど）を置き、その背後にバックエンドのアプリケーションサーバー（Node.js, Unicorn, Tomcatなど）を配置する多層構造が一般的である。このとき、フロントエンドとバックエンドの双方が「1つの持続的接続をどう解釈するか」の認識にズレが生じると、致命的な脆弱性が生まれる。
とりわけ、`Content-Length` ヘッダーと `Transfer-Encoding: chunked` ヘッダーが同時に、あるいは矛盾した形でリクエストに含まれている場合が危険だ。
[攻撃者] –(悪意あるリクエスト)–> [フロントエンド(ALB/Nginx)] –(解釈のズレ利用)–> [バックエンド]
フロントエンドは「ここまでが1つのリクエストだ」と判断してバックエンドに流すが、バックエンド側が `Transfer-Encoding` を優先して解釈した場合、残されたデータが「次のリクエストの先頭部分（Smuggled Request）」として誤認されてしまう。
これにより、管理者権限の奪取やキャッシュポイズニングなど、セキュリティインシデントの温床となる。
対策としてのインフラ設定
この脆弱性を回避するためには、プロキシおよびバックエンドサーバーにおいて、HTTP仕様（RFC 7230など）に厳格に準拠し、曖昧なヘッダーを持つリクエストを即座に拒否（400 Bad Request）するようにチューニングすることが不可欠である。現代の堅牢なインフラストラクチャでは、単に「Keep-Aliveを有効にする」だけでなく、「そのコネクション上で流れるストリームの境界を正確に監視し続ける」プロキシのセキュリティガバナンスが強く求められている。
—
5. LinuxカーネルとTCPバッファの最適化：Keep-Aliveを極限まで活かす
最後に、OSレイヤーまで踏み込んでみよう。HTTPの `Connection: keep-alive` を支えているのは、他でもないLinuxカーネルのTCPスタックである。
アプリケーションが正しく `close()` を呼ばずにコネクションが放置された場合、OSレベルのTCP Keepalive（HTTPのKeep-Aliveとは別物であることに注意）が死活監視を行う。このカーネルパラメータの調整が、大規模Webサービスの安定性を左右する。
`/etc/sysctl.conf` における推奨チューニングの一例を見てほしい。
アイドル状態のコネクションに対して、最初のTCP Keepaliveプローブを送信するまでの時間（秒）
デフォルトの7200秒（2時間）はWebサーバーには長すぎるため、短縮してゾンビ接続を早期発見する
net.ipv4.tcp_keepalive_time = 300
ニ# Keepaliveプローブを再送信する間隔（秒）
net.ipv4.tcp_keepalive_intvl = 15
コネクション切断と判断するまでにプローブを失敗させる回数
net.ipv4.tcp_keepalive_probes = 5
TIME_WAIT状態のソケットを再利用できるようにする（高負荷サーバーのポート枯渇対策）
net.ipv4.tcp_tw_reuse = 1
TCPウィンドウのスケーリングを有効にし、ブロードバンド環境でのスループットを最大化
net.ipv4.tcp_window_scaling = 1
HTTPレイヤーの `keepalive_timeout` と、OSレイヤーの `tcp_keepalive_time`。この2つが調和して初めて、ネットワークの「血管」とも言えるTCPコネクションは健全な血流を保ち続けることができるのだ。
—
結びにかえて
`Connection: keep-alive` というたった行のヘッダー。それは、非効率なTCPハンドシェイクの嵐からWebを救い出した歴史的遺産であり、現代の超高速なインターネット体験を裏で支える静かなる立役者だ。
しかし、その利便性の裏には、リソース管理のジレンマ、パイプライン化の挫折、そしてリクエストスマグリングというダークサイドが潜んでいる。
プロトコルの仕様を斜め読みするのではなく、パケットアナライザを叩き、カーネルのソースコードや挙動に思いを馳せ、フロントからバックエンドまでのトラフィックの全貌をコントロールすること。それこそが、真のインフラアーキテクトやテックリードに求められる視座なのだ。
さあ、あなたの監視画面の向こうで、今日もそのTCPコネクションは美しく再利用されているか？
コメント