ネットワークの「往復ビンタ」を止めろ：HTTP/1.1におけるKeep-Aliveと接続管理の深淵
Webエンジニアとしてキャリアを積んでいると、必ず一度は「なぜかレスポンスが遅い」「高負荷時にTCPコネクションが枯渇する」という壁にぶつかります。その原因の多くは、HTTPというプロトコルの根幹にある「TCPハンドシェイクのコスト」を軽視していることにあります。
今回は、HTTP/1.1の心臓部とも言える「Connectionヘッダー」と「Keep-Alive」について、パケットの裏側で何が起きているのかを紐解いていきましょう。
—
TCPハンドシェイクは「重い」という事実
HTTP/0.9や1.0の時代、リクエストのたびに新しいTCP接続を確立し、終われば切断するのが基本でした。しかし、これには致命的な欠点があります。
1. 3-way Handshake: 通信開始のたびにSYN/SYN-ACK/ACKのやり取りが発生する。
2. Slow Start: TCPの輻輳制御アルゴリズムにより、通信開始直後は転送速度が制限される。
現代のWebサイトのように、1つのページで数百の画像やJSファイルを読み込む環境で、毎回このコストを払うのはあまりにも非効率です。ここで登場するのが、永続的接続（Persistent Connection）です。
—
Connectionヘッダー：制御の司令塔
HTTP/1.1では、デフォルトで接続が維持されます。その制御に使われるのが `Connection` ヘッダーです。
1. `Connection: keep-alive`
「このリクエストが終わっても、接続を切らずに待機していてくれ」というクライアントからのメッセージです。サーバーがこれに応答すれば、TCP接続は温存され、次のリクエストでハンドシェイクを省略できます。
2. `Connection: close`
逆に、もうこれ以上この接続を使わないことを明示します。サーバーがリソースを解放したい時や、クライアントが接続の終了を意図する時に送信します。
—
実践：通信フローとデバッグの極意
実際に `curl` を使って、パケットの挙動を見てみましょう。`-v` オプションはエンジニアの必須ツールです。
-v でヘッダーのやり取りを確認します
curl -v http://example.com/api/data
このとき、レスポンスヘッダーに注目してください。
HTTP/1.1 200 OK
Content-Type: application/json
Connection: keep-alive
Keep-Alive: timeout=5, max=100
- timeout=5: 接続を維持する秒数。
- max=100: この接続を通じて処理できるリクエスト数の上限。
もし、高負荷な環境で `502 Bad Gateway` が頻発する場合、この `timeout` 設定とサーバー側のワーカープロセス数がミスマッチを起こしている可能性を疑ってください。
—
パイプライン処理の幻想と現実
HTTP/1.1には「パイプライン処理」という機能があります。前のリクエストのレスポンスを待たずに、次のリクエストを送りつける手法です。一見高速そうに見えますが、実は「Head-of-Line Blocking（先頭ブロック問題）」という罠があります。
もし最初の処理が重いと、後ろに詰まったリクエストが全て待たされることになります。現代のブラウザの実装では、このパイプライン処理はほぼ無効化されています。HTTP/2以降のマルチプレクシングは、この問題を解決するための抜本的な進化でした。
—
現場で役立つコード例：Pythonでの制御
Pythonの `requests` ライブラリ（`urllib3`ベース）を使う際、接続の効率化には `Session` オブジェクトが必須です。
import requests
Sessionを使うことで、内部的にKeep-Aliveが有効化されます
これにより、同じドメインへのリクエストは同じTCPコネクションを再利用します
session = requests.Session()
接続先の設定を最適化（コネクションプール）
adapter = requests.adapters.HTTPAdapter(
pool_connections=10, # 同時に保持するプール数
pool_maxsize=50 # 各プールごとの最大接続数
)
session.mount(‘https://’, adapter)
response = session.get(‘https://api.example.com/resource’)
print(response.headers.get(‘Connection’)) # 常にkeep-aliveが狙える状態になる
—
シニアからのアドバイス：トラブルシューティングの勘所
現場でネットワークのボトルネックを疑う際、私は必ず以下のコマンドで「接続の再利用率」を推測します。
接続状態を一覧表示（netstat や ss）
ss -nt | grep :80
もし、TIME_WAIT状態のソケットが異常に多い場合、アプリケーション側が `Connection: close` を乱発しているか、あるいはサーバー側のKeep-Aliveタイムアウト設定が短すぎて、クライアントとサーバーで「閉じたり開いたり」の無駄な応酬が発生している可能性があります。
結論として：
HTTP/1.1を使いこなすということは、TCPという「土管」をいかに有効活用するかというゲームです。設定ファイルをいじる前に、まずはクライアントとサーバーがどのような対話（ヘッダーのやり取り）をしているのか、そのパケットの息遣いを感じ取ることから始めてみてください。
技術は常に進化しますが、この「Connection」という概念を理解しているか否かで、インフラ設計の強度が決定的に変わります。何かあれば、いつでもまた聞いてください。共に現場を支えていきましょう。
コメント