ネットワークスペシャリストが語る「Connection: keep-alive」の深層：HTTP/1.1の持続的接続と現場の流儀
こんにちは。これまでに数え切れないほどのWebサービスの立ち上げに立ち会い、夜中の障害対応で何度冷や汗をかいてきたことか……。インフラやネットワークの世界に身を置いていると、「なぜかAPIのレスポンスが妙に遅い」「高負荷時にTCPのTIME_WAIT枯渇でサーバーが沈黙する」といったトラブルに幾度となく直面します。
その原因の多くは、HTTPの土台を支えるTCPコネクションのライフサイクル、そして今回焦点を当てる `Connection: keep-alive` の挙動を誤解していることにあります。
教科書的なRFCの定義をなぞるだけなら誰でもできます。しかし、実際にパケットキャプチャ（Wireshark）を眺め、Nginxやアプリケーションの裏側で何が起きているのかを肌で知っているエンジニアこそが、真に堅牢なWeb APIやインフラを設計できるのです。
今回は、HTTP/1.1の持続的接続（Persistent Connection）のメカニズムを解き明かし、実務で絶対に知っておくべきパラメーター、設定のベストプラクティス、そして現場で使えるデバッグ手法まで、シニアの視点からたっぷりと解説します。
—
1. なぜ「Keep-Alive」が必要だったのか？ —— HTTP/1.0の暗黒時代
HTTP/1.1の仕様（RFC 2068 / RFC 7230）が策定される前、HTTP/1.0の時代は悲惨でした。
当時のWebページは、HTMLテキスト1つをフェッチするたびにTCPの3ウェイハンドシェイク（SYN -> SYN-ACK -> ACK）を行い、データを取得したら即座に `FIN` パケットを送ってコネクションを切断していました。
CSSや画像、JavaScriptが数十個あるモダンなページを想像してください。ブラウザはそれらを取得するために、わざわざ何十回もTCPの確立と切断を繰り返していたのです。
これをネットワークの視点で見るとどうなるか？
- RTT（Round Trip Time）の無駄: データの往復だけでなく、コネクション確立のためのオーバーヘッドが毎リクエストに発生する。
- TCPのスロースタート問題: 新しいTCPコネクションは、輻輳制御（Congestion Control）のために最初は小さなウィンドウサイズから徐々に転送速度を上げていきます。つまり、毎回コネクションを張る行為は、常に「ノロノロ運転」からスタートさせられているのと同じです。
- TIME_WAITの嵐: サーバー側には、切断されたコネクションが `TIME_WAIT` 状態（通常は60秒間）として残り続け、高負荷時にはポートが枯渇して新規接続を受け付けなくなる。
この非効率を打破するためにHTTP/1.1で標準化されたのが、「一度確立したTCPコネクションを維持し、複数のリクエスト/レスポンスで使い回す」 という持続的接続（Persistent Connection）です。
—
2. `Connection: keep-alive` の通信フローと実際の挙動
HTTP/1.1では、特段の指定がない限りデフォルトで持続的接続が有効になっています（Implicit Keep-Alive）。つまり、クライアントもサーバーも明示的に切断を要求しない限り、TCPコネクションは開きっぱなしになります。
では、HTTPヘッダーのやり取りが実際どうなっているのか、シーケンスを見てみましょう。
シーケンスのイメージ
Client Server
| |
|— [1] TCP 3-Way Handshake (SYN) ————->|
|<-- [2] SYN-ACK --------------------------------|
|--- [3] ACK ----------------------------------->|
| |
|— [4] GET /api/v1/users HTTP/1.1 ————>|
| Host: api.example.com |
| Connection: keep-alive |
| |
|<-- [5] HTTP/1.1 200 OK ------------------------|
| Content-Length: 124 |
| Connection: keep-alive |
| (レスポンスボディ送信) |
| |
| --- (同じTCPコネクションを再利用) --- |
| |
|--- [6] GET /api/v1/items HTTP/1.1 ------------>|
| Host: api.example.com |
| |
|<-- [7] HTTP/1.1 200 OK ------------------------|
| Content-Length: 256 |
| |
| --- 一定時間アイドル状態 --- |
| |
|--- [8] FIN (切断要求) ------------------------>|
|<-- [9] ACK / FIN ------------------------------|
ここで重要なポイントがあります。HTTP/1.1の仕様上、クライアントは `Connection: keep-alive` を明示しなくても持続的接続を期待しますが、プロキシサーバーや古いHTTP/1.0クライアントとの後方互換性を考慮して、明示的にヘッダーを付与することが今でも実務では行われます。
---
3. 現場でハマる！ Keep-Aliveのパラメーターと「タイムアウト」の罠
コネクションを維持し続けるということは、サーバーのリソース（メモリやファイルディスクリプタ）を消費し続けると同義です。無限に接続を保持し続けたら、サーバーはあっという間にリソース枯渇を起こしてダウンします。
そのため、インフラエンジニアは必ずタイムアウト設定と最大リクエスト数を適切にチューニングしなければなりません。
代表的なチューニングパラメーター（Nginxの例）
実際のWebサーバー設定（ここではNginx）を例に、現場で必ず調整するパラメーターを見てみましょう。
http {
# 1つのKeep-Aliveコネクション上で処理できる最大リクエスト数
# これを超えると、サーバー側からコネクションを切断します（過度なリソース占有を防ぐ）
keepalive_requests 1000;
# Keep-Aliveコネクションのアイドル状態を保持するタイムアウト時間
# クライアントからの次のリクエストがこの秒数来なければ、サーバーから切断します
keepalive_timeout 65;
# アップストリーム（バックエンドのアプリケーションサーバー）へのKeep-Alive接続数
# リバースプロキシを構築する際、バックエンドとのコネクションプールを維持するために超重要
upstream backend_servers {
server 10.0.1.10:8080;
server 10.0.1.11:8080;
# アイドル状態のバックエンドコネクションをキャッシュしておく数
keepalive 32;
}
}
実務での教訓：ロードバランサー（ALB/ELB）とのタイムアウト値の不一致
AWSのALB（Application Load Balancer）などのロードバランサーの後段にNginxやEC2を配置している場合、「ALBのアイドルタイムアウト値」と「Nginx/バックエンドの `keepalive_timeout` 値」の関係に頭を悩まされた人は多いはずです。
- 教訓: バックエンド側のタイムアウト値を、ロードバランサー側のタイムアウト値より少し長め（数秒余裕を持たせる）に設定してください。
- 理由: バックエンドが先にコネクションをプツッと切断してしまうと、ロードバランサーがその瞬間に届いたリクエストを流してしまい、クライアントに `502 Bad Gateway` が返るという極めて厄介なレースコンディション（Transient Error）が発生するためです。
—
4. 各種言語・ツールにおけるKeep-Aliveの実装・検証サンプル
「理論は分かったけれど、自分のコードやスクリプトでどう意識すべきか？」
ここからは、実務の現場ですぐに使える具体的なコード例と検証手法を紹介します。
① cURLでKeep-Aliveの挙動を直接目撃する
デバッグの基本は、プロトコルの生データを見ることに他なりません。cURLを使って、同じコネクションで複数回リクエストを送る（HTTPピペライジングや連続リクエスト）様子を確認してみましょう。
-v (–verbose) をつけて、TCPコネクションの確立と再利用のログを出力する
–next を使うことで、同一のセッション/コネクションで連続してリクエストを投げられます
curl -v https://httpbin.org/get \
–next https://httpbin.org/headers
コンソール出力を注意深く見ると、2回目のリクエスト時に `Re-using existing connection! host: httpbin.org port: 443` というログが出現し、新しいSYNパケットが流れていないことが確認できます。
② Node.js (Fetch API) でのコネクション再利用
現代のJavaScript（Node.js 18+のネイティブFetchなど）では、デフォルトでKeep-Aliveが有効なHTTPエージェントが背後で働いています。しかし、高スループットなAPIクライアントを書く場合は、明示的に `Agent` の設定をチューニングすることがあります。
import http from ‘http’;
import https from ‘https’;
// カスタムエージェントを作成し、Keep-Aliveとプール数をチューニング
const keepAliveAgent = new http.Agent({
keepAlive: true,
keepAliveMsecs: 1000, // Keep-Aliveパケットを送信する頻度（ミリ秒）
maxSockets: 100, // 同時オープン可能な最大ソケット数
maxFreeSockets: 10, // アイドル状態で保持する最大ソケット数
timeout: 60000 // ソケットのタイムアウト
});
// 使用例（実際のリクエストにエージェントを渡す）
// ※ ネイティブfetchを使う場合は環境やライブラリ（undici等）の仕様に依存します
③ Python (requests) でのセッション管理
Pythonの `requests` ライブラリで何も考えずに `requests.get()` を呼び出すと、実は毎回リクエストごとにTCPコネクションが破棄・再作成されます。ループ内で大量のAPIリクエストを投げる場合は、必ず `requests.Session()` を使ってコネクションをプール（Keep-Alive）してください。
import requests
Sessionオブジェクトを利用することで、内部の urllib3 が Keep-Alive を維持します
with requests.Session() as session:
# 1回目のリクエスト（ここでTCP 3-Way Handshakeが発生）
response1 = session.get(‘https://httpbin.org/get’)
print(f”Request 1 Status: {response1.status_code}”)
# 2回目のリクエスト（同じTCPコネクションが再利用されるため圧倒的に高速）
response2 = session.get(‘https://httpbin.org/ip’)
print(f”Request 2 Status: {response2.status_code}”)
print(f”Client IP: {response2.json().get(‘origin’)}”)
—
5. まとめ：モダンインフラにおけるHTTP/1.1 Keep-Aliveの位置づけ
ここまで、HTTP/1.1における `Connection: keep-alive` の裏側と実務的なTipsを解説してきました。
- TCPハンドシェイクのオーバーヘッドを削減することが最大の存在意義。
- サーバー側・プロキシ側のタイムアウト値の整合性を設計しないと、502/504エラーの温床になる。
- アプリケーションコード（Pythonの `requests` など）では、セッション管理を行わないと意図せず毎回コネクションが切断される。
現在、世の中はHTTP/2やHTTP/3（QUIC）へとシフトしつつあります。HTTP/2では1本のTCPコネクション上で完全な多重化（Multiplexing）が行われるため、HTTP/1.1のような「Head-of-Line Blocking（先頭ブロック化）」の悩みからは解放されました。
しかし、その土台にあるTCPの仕組み、あるいはレガシーシステムや内製プロキシを挟むモダンなアーキテクチャにおいては、依然としてHTTP/1.1の `Keep-Alive` の挙動を理解しているかどうかが、プロとアマを分ける分水嶺となります。
インフラの挙動に迷ったときは、教科書を開く前にまずパケットをキャプチャし、コネクションのライフサイクルに思いを馳せてみてください。きっと、障害の原因は静かにパケットの中に隠されているはずです。
コメント