HTTP/1.1の永続接続：なぜ私たちは「TCPハンドシェイクの呪縛」から解放される必要があったのか
ネットワークエンジニアの端くれとして、TCP/IPのパケットキャプチャを眺める時間は至福だ。しかし、HTTP/1.0時代のパケットの並びを見るたびに、私は「なぜこれほどまでに非効率な旅を繰り返していたのか」と溜息をつきたくなる。
ブラウザが1つのページを表示するたび、画像やスタイルシートのために接続を張り、データを取得し、即座に`FIN`を投げて切断する。この「ワンショット通信」は、インフラエンジニアから見れば悪夢そのものだ。TCPの3-wayハンドシェイクという儀式を、オブジェクトをフェッチするたびに繰り返す。そこにTLSが加われば、暗号化のネゴシエーションという重厚なオーバーヘッドがさらに上乗せされる。
HTTP/1.1で導入された「永続接続（Keep-Alive）」は、単なる機能追加ではない。それは、ネットワークの物理的な制約に対する、プロトコル層からの静かなる反乱だったのだ。
TCPハンドシェイクのコストを再考する
現代のWebにおいて、RTT（Round Trip Time）は最大の敵だ。クライアントが物理的に遠方にいればいるほど、3-wayハンドシェイクの遅延は累積し、ユーザーの離脱率を押し上げる。
HTTP/1.1の永続接続は、`Connection: keep-alive`ヘッダーを通じて、サーバーとクライアントに対して「このTCPセッションは、終わった後もそのままにしておけ」と告げる。これにより、2回目以降のリクエストは、OSのソケットバッファを再利用し、即座にHTTPリクエストを流し込むことができる。
カーネルレベルの視点：TCPバッファと再利用
サーバー側（特にLinux）で永続接続を扱う際、重要になるのが`tcp_keepalive_time`や`tcp_max_syn_backlog`といったカーネルパラメータだ。接続を長時間維持するということは、それだけサーバーのリソース（メモリ）を占有することを意味する。
sysctlでのチューニング例
接続維持時間を短縮し、ゾンビセッションによるメモリ枯渇を防ぐ
net.ipv4.tcp_keepalive_time = 300 # アイドル状態から300秒でプローブ開始
net.ipv4.tcp_keepalive_intvl = 15 # プローブの送信間隔を15秒に
net.ipv4.tcp_keepalive_probes = 5 # 5回失敗したら切断とみなす
暗号化の重圧：TLSセッション再開との協調
HTTP/1.1の永続接続が真価を発揮するのは、TLSと組み合わさったときだ。暗号化のハンドシェイク（ClientHello/ServerHello）は、TCPハンドシェイクよりもはるかにコストが高い。
永続接続は、一度確立したTLSセッションのパラメータを維持したまま、複数のHTTPリクエストをカプセル化する。ここで重要になるのが「TLS Session Resumption」との併用だ。仮にTCP接続が切れてしまっても、セッションIDやセッションチケットを利用すれば、フルハンドシェイクを回避して最短のRTTで再接続できる。
アーキテクトとしては、この「TCPの持続性」と「TLSの再開」を両輪として設計する必要がある。
脆弱性と最適化のトレードオフ：HTTPパイプライン化の幻影
HTTP/1.1には「パイプライン化」という機能もあった。レスポンスを待たずに次のリクエストを投げつける技術だが、これは現場では「パンドラの箱」として扱われることが多かった。
- ヘッド・オブ・ライン・ブロッキング（HOLB）: 前の大きなリクエストが詰まると、後ろの小さなリクエストがすべて待たされる。
- ミドルボックスの誤作動: 古いプロキシやルーターが、連続するパケットを正しく解釈できず破棄することがあった。
現代のインフラ設計では、HTTP/1.1の永続接続は「1コネクション1リクエストの並列化」というよりは、「コネクションプーリングの効率化」として捉えるのが賢明だ。
推奨される実装指針
実務において、Nginxなどで永続接続を最適化する際は、以下の設定が基準となる。
Nginxの設定例：keepaliveのハンドリング
keepalive_timeout 65; # 接続維持時間。長すぎればメモリ不足、短すぎれば再ハンドシェイクの嵐
keepalive_requests 1000; # 1つの接続で処理するリクエスト上限。高負荷時は適宜調整
upstreamでの設定（バックエンドへの接続維持）
upstream backend_app {
server 127.0.0.1:8080;
keepalive 32; # バックエンドへの接続をキャッシュする個数
}
終わりに：次世代への橋渡し
HTTP/1.1の永続接続は、HTTP/2のマルチプレキシングやHTTP/3のQUICに至るまでの、壮大な「つなぎ」の歴史と言えるかもしれない。しかし、今なお多くのWebサービスで、このレガシーかつ強力な仕組みがトラフィックの屋台骨を支えている。
「接続を再利用する」というシンプルな概念が、どれほどのパケットを減らし、どれほどのCPUサイクルを節約しているか。それを想像しながら`tcpdump`のログを眺めれば、見慣れたネットワーク通信も違った景色に見えてくるはずだ。
次にパケットを解析する際は、ぜひ`Connection: keep-alive`がどのようにセッションを繋ぎ止め、TCPスタックがそれをどう処理しているかに着目してほしい。インフラの本質は、常にこうした「泥臭いプロトコルの積み重ね」の中に眠っているのだから。
コメント