HTTP/1.1の深淵：TCP接続を「使い回す」ことの真価と限界
ネットワークエンジニアの端くれとして、パケットキャプチャを眺める時間は至福だ。Wiresharkのタイムラインに並ぶ SYN、SYN-ACK、ACK の三部作。その後に続く TLS Client Hello からのハンドシェイク。これらが完結して初めて、我々が愛する HTTP/1.1 のペイロードが流れる。
現代のWebにおいて、この「接続確立」というコストは、まさに聖杯を求めるような重い代償だ。今回は、HTTP/1.1における Connection: keep-alive が、単なる「接続維持」という言葉を超えて、インフラ層にどのような恩恵と呪いをもたらすのかを、深層から紐解いていく。
—
1. 接続再利用という名の「泥臭い」効率化
HTTP/1.0 時代、ブラウザはリソースひとつ（画像やJS）を取得するたびにTCPの3ウェイ・ハンドシェイクを繰り返していた。レイテンシが数十ミリ秒の世界では、RTT（Round Trip Time）が積み重なるだけでユーザー体験は死ぬ。
ここで登場した Connection: keep-alive は、TCP接続を即座に破棄せず、ソケットをプール（再利用）する道を開いた。
パケットレベルでの挙動
HTTP/1.1の仕様では、明示的に Connection: close が送られない限り、接続は維持されると見なされる。バックエンドのロードバランサー（NginxやHAProxy）でこの挙動を制御することは、パフォーマンステューニングの要諦だ。
# NginxにおけるKeep-Aliveの設定例
http {
# クライアントからの接続を保持する時間
keepalive_timeout 65;
# ひとつのキープアライブ接続で処理するリクエスト数
keepalive_requests 1000;
# 上流（アップストリーム）との接続保持設定
upstream backend {
server 127.0.0.1:8080;
keepalive 32; # バックエンドへの接続を保持し、再利用する数
}
}この設定の肝は、keepalive ディレクティブだ。これがないと、バックエンドとの通信のたびにOSカーネルは TIME_WAIT 状態のソケットを量産し、高負荷時にはエフェメラルポート枯渇という「死の淵」へと突き進むことになる。
—
2. パイプライン化の挫折とTCPバッファの現実
HTTP/1.1には Pipeline という野心的な仕様があった。リクエストに対するレスポンスを待たずに、次のリクエストを投げ続けるというものだ。しかし、これは「Head-of-Line Blocking（HOLB）」という名の呪いによって実質的に葬り去られた。
あるパケットがロスすれば、後続のすべてのリクエストがTCPの再送制御によって停止する。この挙動を回避するためには、カーネルレベルのチューニングが不可欠だ。
# LinuxカーネルのTCPウィンドウサイズを最適化する
# 帯域幅遅延積(BDP)を考慮し、バッファを拡大する
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"
# TCP Fast Openを有効化し、ハンドシェイクのRTTを削減する
sysctl -w net.ipv4.tcp_fastopen=3tcp_fastopen は、3ウェイ・ハンドシェイクの最初の SYN パケットにデータを同梱させる技術だ。セキュリティ専門家であれば、これがIPスプーフィングを利用した攻撃のリスクを微増させることは承知の上だろうが、パフォーマンスを追求する現場では欠かせないカードとなる。
—
3. セキュリティとパフォーマンスの均衡点
HTTP/1.1ヘッダーは平文であるため、当然のように TLS でラップする必要がある。ここで問題となるのが、TLSのハンドシェイクコストと Connection: keep-alive の依存関係だ。
もし keep-alive が適切に機能していれば、TLSセッション再開（Session Resumption）を利用することで、完全なハンドシェイクを省略できる。
セキュリティ上の注意点
接続を長く維持することは、攻撃者に「セッションハイジャック」や「リソース占有攻撃」の機会を与えることと同義だ。以下のセキュリティ対策を必ず検討すること。
- Timeoutsの厳格化: 不要な接続は
keepalive_timeoutで容赦なく切断する。 - ヘッダーサイズ制限:
client_header_buffer_sizeを絞り、巨大なヘッダーによるメモリ枯渇攻撃（Slowloris等）を防御する。 - HTTP/2への移行検討: そもそもHTTP/1.1のHOLBを克服する目的で生まれたHTTP/2やHTTP/3は、多重化において次元が異なる。アーキテクトとして「いつHTTP/1.1を捨てるか」を見極める決断も重要だ。
—
最後に：プロトコルの美学
HTTP/1.1は古臭いと言われるが、その挙動を深く理解することは、現代の複雑なスタックをデバッグする際、最も信頼できる武器になる。パケットが ACK を返し、OSがソケットをプールし、アプリケーションがレスポンスを返す。この一連のダンスを脳内で可視化できるエンジニアこそが、真の「境界防御」を担えるのだと私は信じている。
泥臭い設定ファイルのチューニングの先にしか、極限のパフォーマンスは存在しない。次のメンテナンスウィンドウでは、ぜひ ss -ant コマンドを叩いて、自分の作ったTCP接続がどれだけ「再利用」されているかを確認してみてほしい。そこには、君が書いたコードの真の姿が映っているはずだ。
コメント