TCPの「重い鎖」を断ち切る：HTTP/1.1 Keep-Aliveが変えたネットワークの風景
インフラエンジニアとして現場に立つとき、我々は常に「レイテンシ」という見えない敵と戦っている。HTTP/0.9や1.0の時代、ブラウザが画像ひとつ、CSSひとつを読み込むたびに、その裏で何が起きていたか。TCPの3-wayハンドシェイク、そしてTLSハンドシェイク。これらがリクエストのたびに繰り返される光景は、現代のWebのスケールからすれば、まさに「非効率の極み」であった。
HTTP/1.1において、Keep-Alive（Persistent Connection）がデフォルト化されたことは、単なる仕様の変更ではない。これは、トランスポート層のオーバーヘッドを「最小化」し、インターネットという広大な非同期空間をいかに効率的に使い倒すかという、アーキテクトにとっての最初の大きな転換点だったのだ。
—
TCPハンドシェイクの「コスト」を再定義する
パケットレベルで考えてみよう。HTTP/1.0では、リクエストごとに `SYN` -> `SYN/ACK` -> `ACK` というTCPハンドシェイクが走り、さらにTLS化された環境では、そこに `Client Hello` から始まる暗号化ネゴシエーションが重なる。
物理的な距離が遠いクライアントほど、このRTT（Round Trip Time）の積み重ねは致命的な遅延を生む。HTTP/1.1の永続接続（Persistent Connection）は、一度確立したTCPコネクションを `Connection: keep-alive` ヘッダーによって維持し、複数のリクエストを同じセッション上でパイプライン化――あるいは少なくとも逐次処理――することで、この「最初の1マイル」の無駄を劇的に排除した。
TCPバッファとウィンドウサイズへの影響
永続接続を運用する際、注意すべきはカーネルレベルのチューニングだ。コネクションが長生きするということは、TCPウィンドウサイズが適切にスケーリングされる恩恵を受けられる反面、ゾンビ化したコネクションがリソースを食いつぶすリスクとも隣り合わせになる。
Linuxカーネルにおいて、高トラフィックなサーバーを運用する際は、以下のパラメーターを意識せざるを得ない。
TCPの送信バッファと受信バッファの自動チューニング範囲を最適化
大規模なKeep-Alive環境では、メモリ許容範囲で上限を引き上げる
sysctl -w net.ipv4.tcp_rmem=”4096 87380 16777216″
sysctl -w net.ipv4.tcp_wmem=”4096 65536 16777216″
Keep-Aliveのタイムアウト設定（TCPレベルの監視）
接続を維持しつつ、無駄なリソースを解放するバランスが重要
sysctl -w net.ipv4.tcp_keepalive_time=600 # 10分間通信がなければプローブ開始
sysctl -w net.ipv4.tcp_keepalive_intvl=10 # プローブ間隔
sysctl -w net.ipv4.tcp_keepalive_probes=6 # 6回失敗で切断
—
Connectionヘッダーとプロキシの罠
HTTP/1.1における `Connection: close` と `keep-alive` の明示は、プロキシやロードバランサーとの親和性を高めるための「作法」だ。しかし、ここでセキュリティの観点から忘れてはならないのが、ホップ・バイ・ホップヘッダーの扱いである。
`Connection` ヘッダーは、転送先のサーバーにその値を伝搬させてはならない。もしプロキシがこのヘッダーを透過的に通してしまい、かつバックエンドが異なるプロトコル解釈をしていた場合、HTTP Request Smuggling という深刻な脆弱性を招く。
現代のインフラアーキテクトは、単に「接続を維持する」だけでなく、その接続が「どこからどこまで有効か」を厳密に制御する必要がある。
—
TLSハンドシェイクのオーバーヘッド削減：現代の最適化手法
HTTP/1.1のKeep-Aliveを最大限に活かすには、TLSのハンドシェイクコストをいかに「無」にするかが鍵となる。
1. TLS False Start: クライアントが `Change Cipher Spec` を送信した直後にアプリケーションデータを送り出す機能。TCPの3-wayハンドシェイク完了直後にデータを乗せられるため、RTTを大幅に削れる。
2. Session Resumption (TLS Session Tickets): 過去のセッション情報を暗号化してクライアントに保持させ、再接続時にハンドシェイクを省略する。
これらの技術を組み合わせることで、HTTP/1.1であっても、現代のWebアプリケーションに求められるレスポンス速度の境界線まで到達できる。
—
結論：HTTP/1.1は「レガシー」か？
「HTTP/2やHTTP/3がある今、なぜHTTP/1.1のKeep-Aliveを語るのか？」という問いが聞こえてきそうだ。答えはシンプルだ。
HTTP/3（QUIC）であれHTTP/2（Multiplexing）であれ、その本質的な思想は、HTTP/1.1が確立した「TCP接続を使い回す」というコンセプトの極致に他ならないからだ。TCPハンドシェイクを1回に集約し、いかに効率よくパケットを詰め込むか。この戦いは、1990年代後半の技術者が直面した課題と、本質的に何も変わっていない。
インフラアーキテクトとして、まずはHTTP/1.1の挙動をパケットキャプチャで追ってみてほしい。`FIN` パケットがいつ飛ぶのか、`Keep-Alive` タイマーがサーバーの `nginx.conf` や `apache2.conf` でどう振る舞っているのか。その詳細を理解した者だけが、HTTP/2やその先のプロトコルを「本当の意味で使いこなす」資格を得るのである。
技術の進化は積み重ねだ。HTTP/1.1の知見を軽視する者に、次世代プロトコルのパフォーマンスチューニングなど到底不可能である。さあ、今夜は `tcpdump` を片手に、パケットの呼吸を感じるところから始めてみようではないか。
コメント