【入門編】HTTP/1.1の永続接続(Keep-Alive)の設計概念 – HTTPプロトコル・通信規格実践ガイド

WEBサイトを開こうとしたとき、一瞬だけ「カクッ」と止まるような感覚を覚えたことはありませんか？実はその裏側で、ネットワークは必死に「接続の準備」を繰り返しています。

今日は、WEB通信の歴史において「革命的」と言っても過言ではない、HTTP/1.1の「永続接続（Keep-Alive）」という仕組みについて紐解いていきましょう。

—

HTTPの初期（HTTP/1.0の頃まで）の通信を、郵便配達に例えてみましょう。

当時の通信は、こんなルールでした。
1. 「手紙（リクエスト）を届けます！」と玄関まで走る（TCPの接続）
2. 手紙を渡して、返事を受け取る（データのやり取り）
3. 「はい、お疲れ様でした！」とわざわざ郵便局まで戻る（接続の切断）

たった一通の手紙（画像一枚、HTML一行）のために、毎回「行って、帰る」を繰り返していたら、どうなるでしょうか？もしWEBページに100個の画像があったら、100回も往復しなければなりません。これは、あまりにも効率が悪いですよね。

この「行くたびに接続し、終わったらすぐ切る」という行為は、ネットワーク機器にとって「TCPのハンドシェイク」という非常に重い手続きを毎回発生させており、通信が遅くなる最大の原因だったのです。

そこで登場したのが、HTTP/1.1の「永続接続（Keep-Alive）」です。

先ほどの郵便配達の例えをアップデートしてみましょう。
「終わったらすぐ帰る」のをやめて、「一旦、玄関前で待機して、次の手紙が来たらすぐ渡せるようにしよう！」という仕組みです。

一度接続を確立したら、サーバーとブラウザの間で「まだ繋いでいようか」「うん、そうしよう」という合意さえ取れれば、何度も何度も同じ道路（TCP接続）を使って、効率よく荷物を運び続けることができます。

この「繋ぎっぱなしにしておいて！」という合意形成に使われるのが、有名な `Connection: keep-alive` というヘッダーです。

ブラウザがサーバーに対して、「このデータを受け取った後も、この道（接続）は閉じないでね！」とメッセージを送るための「合言葉」のようなものですね。

ブラウザ（クライアント）からサーバーへ送られる通信の中身は、こんなイメージです。

GET /index.html HTTP/1.1
Host: example.com
Connection: keep-alive # 「この後もこの接続を維持して！」という合言葉

もしサーバー側がこのリクエストを受け取って、「わかった、繋いだままにしておくよ！」と返事をしてくれれば、その後は接続を維持したまま、同じTCPコネクションの上で画像やスタイルシートを次々とダウンロードできるようになります。

ネットワークの現場では、この「接続の維持」がパフォーマンスを左右する死活問題になります。

オーバーヘッドの削減: 接続を確立するためのやり取り（SYN/ACKパケット）を省略できるため、ページ表示までの時間が劇的に短縮されます。
CPU負荷の軽減: 接続を「張って、切って」を繰り返すと、サーバーのCPUは接続処理だけで手一杯になってしまいます。Keep-Aliveは、サーバーの負担を減らす「省エネ設計」でもあるのです。

ずっと繋ぎっぱなしだと、サーバーのメモリがパンクしてしまいますよね。そのため、現実には「5秒間何も通信がなかったら切る」や「100リクエスト捌いたら切る」といったタイムアウトの設定が行われます。

NginxなどのWebサーバー設定では、以下のように調整します。

nginx.conf の設定例
keepalive_timeout 65; # 65秒間通信がなければ接続を閉じる設定
keepalive_requests 100; # 100回リクエストを処理したら接続を入れ替える設定

—

HTTP/1.1のKeep-Aliveは、単なる「接続の維持」ではありません。「無駄な往復を減らし、より少ない労力で多くの情報を届ける」という、インフラ設計の基本思想そのものです。

「接続」という目に見えない道を、どうやって効率よく使い回すか。これを知っておくだけで、ブラウザでサイトを開いた時の「速さ」の理由が見えてくるはずです。

次回は、この「一つの接続を使い回す」ことの副作用と、それをさらに進化させたHTTP/2の世界についてお話しできればと思います。エンジニアへの道は、こうした小さな「なぜ？」を積み重ねることから始まります。一歩ずつ、一緒に歩んでいきましょうね！