接続の「再利用」が切り拓く地平：HTTP/1.1 `Keep-Alive` の深層と、パケットの鼓動
ネットワークエンジニアにとって、HTTP/1.1は単なるプロトコルではなく、TCPという「荒ぶる制御」とどう折り合いをつけるかという壮大な実験場だ。
HTTP/0.9や1.0の時代、TCP接続はリクエストごとに生成され、捨てられていた。3ウェイ・ハンドシェイク（SYN/SYN-ACK/ACK）のオーバーヘッド、そしてTCP Slow Startの呪縛。これらがWebのパフォーマンスを文字通り「物理的」に遅延させていた。HTTP/1.1で導入された永続的接続（Persistent Connection）は、単なる機能追加ではない。TCPというトランスポート層を、HTTPというアプリケーション層が「飼いならす」ための歴史的転換点だったのだ。
`Connection: keep-alive` が生み出す「静かなる効率化」
HTTP/1.1において、デフォルトで接続は維持される。ここで重要なのは `Connection` ヘッダーの制御だ。
クライアントが `Connection: keep-alive` を送信し、サーバーがそれに応答することで、TCPセッションは閉じられずに待機状態へと移行する。ここで真に語るべきは、「ACKを待つ時間の節約」ではない。「SYNパケットのコスト削減」だ。
TLS 1.2以前、あるいはTLS 1.3であっても、暗号化ハンドシェイクにはRTT（Round Trip Time）が費やされる。接続を再利用することは、この重いハンドシェイクをスキップし、いきなりアプリケーション層のペイロードを送り込めることを意味する。
カーネルレベルのチューニング：TCPバッファと`keepalive`タイマー
アプリケーションで `keep-alive` を許可しても、OSのTCPスタックがそれを無駄にしては意味がない。高負荷なWebサーバーでは、以下のsysctl設定が「接続の寿命」を決定づける。
TCPキープアライブのプローブ送信までのアイドル時間（秒）
net.ipv4.tcp_keepalive_time = 600
プローブを送信する間隔（秒）
net.ipv4.tcp_keepalive_intvl = 75
接続を強制切断するまでのプローブ失敗回数
net.ipv4.tcp_keepalive_probes = 9
この設定により、接続がアイドル状態の際、カーネルは定期的に「生きてるか？」とパケットを投げる。これにより、ファイアウォールやロードバランサーが「無通信状態」とみなしてTCPセッションを強制切断（アイドルタイムアウト）するのを防ぐことができる。
パイプライン処理の幻影と現実
HTTP/1.1の仕様書には「パイプライン処理」という野心的な機能がある。レスポンスを待たずに次のリクエストを投げ込む技術だ。しかし、現場のインフラエンジニアはこれを使わない。なぜか？
それは、「Head-of-Line Blocking（先頭行のブロッキング）」という回避不能な悪夢に直面するからだ。
1. リクエストAを送る。
2. リクエストBを送る。
3. サーバーはリクエストAの処理に時間がかかっている間、リクエストBの処理が終わってもAを送り終えるまでBを返せない。
この制約により、パケットロスが発生した瞬間、TCPの再送制御によって後続のすべてのリクエストがブロックされる。現代のアーキテクチャでは、パイプラインを無理に使うより、ドメインシャーディングや、最終的にはHTTP/2のストリーム多重化へと移行するのが「正解」である。
`Connection: close` が教える「引き際の美学」
一方で、`Connection: close` は決して「悪」ではない。
ロードバランサー（L7 LB）やリバースプロキシを介した構成では、バックエンドサーバーのソケットを枯渇させないために、あえて `close` を選択することがある。特に、長時間稼働するプロセスでメモリリークのリスクがある場合、あるいは特定の処理後に接続をクリーンに保ちたい場合、意図的にTCPセッションをクローズするのは立派な戦略だ。
Nginxでバックエンドへの接続を強制的にクローズさせる例
location /api/v1/heavy-task {
proxy_pass http://backend_pool;
# 明示的にcloseを指定してTCPセッションを使い回さない
proxy_set_header Connection “close”;
}
セキュリティの視点：接続再利用の代償
接続を再利用するということは、「同じTCPセッションを使い続ける」ということだ。これは、DoS攻撃における「スローローリス攻撃（Slowloris）」に対して、サーバーを脆弱にする側面がある。
一つのコネクションを長く維持させることは、リソースの節約になる一方で、攻撃者が少ないコネクションでサーバーの同時接続数上限を埋め尽くす隙を与える。
インフラアーキテクトとしては、以下のバランスが必須となる。
1. `keepalive_timeout` を適切に設定し、不要な接続は速やかに解放する。
2. `limit_conn` モジュールを活用し、同一IPからの同時接続数を制限する。
3. TLS 1.3の「0-RTT」など、接続再利用の利点を享受しつつ、リプレイ攻撃を防ぐ設計を組み合わせる。
結論：パケットに「意味」を持たせる
HTTP/1.1の `Connection` ヘッダー制御は、現代のHTTP/2やHTTP/3の多重化・QUICへと繋がるプロトコルの進化の礎だ。
「接続を繋ぎっぱなしにすれば速い」という単純な理解から脱却し、TCPのフロー制御、カーネルのスタック挙動、そしてセキュリティのトレードオフを俯瞰する。それこそが、世界最高峰のインフラアーキテクトに必要な視座である。
次にパケットキャプチャを開いたとき、単なる `Keep-Alive` の文字列ではなく、その裏で静かに効率化されているTCPハンドシェイクの「音」を聞き取ってほしい。ネットワークは、いつだって技術者の理解を待っているのだから。
コメント