【入門編】HTTP/1.1のConnection: keep-aliveヘッダーによる持続的接続の最適化 – HTTPプロトコル・通信規格実践ガイド

こんにちは！ネットワークの深淵を旅する皆さん、ようこそ。

今日は、Webブラウザの裏側で当たり前のように行われている「接続のバトンタッチ」、HTTP/1.1の「Keep-Alive（持続的接続）」という仕組みについてお話ししましょう。

「Webサイトがなかなか表示されないな」と感じたとき、実はネットワークの裏側では、郵便屋さんが毎回ドアをノックするたびに鍵を開けて閉めて……という非効率なやり取りが起きているかもしれません。この「鍵の開け閉め」を効率化する、インフラエンジニアの必須教養を紐解いていきます。

—

HTTP/1.0の頃まで、Web通信は非常に律儀でした。ブラウザがサーバーに「画像ちょうだい！」と頼むたびに、こんな手順を踏んでいたのです。

1. 接続（TCPコネクションの確立）： 郵便屋さんがドアを叩いて挨拶をする。
2. 要求（リクエスト）： 「画像ください！」と手紙を出す。
3. 応答（レスポンス）： 郵便屋さんが画像を持ってくる。
4. 切断（クローズ）： 挨拶をしてドアを閉める。

これ、1つのページに画像が100枚あったら、100回も「ドアをノックして挨拶して、帰る」を繰り返すことになります。これがどれほど無駄か、想像できますよね？この往復にかかる時間（RTT：Round Trip Time）が、Webの表示速度を殺していたわけです。

そこで登場したのが、HTTP/1.1の革命「Keep-Alive（持続的接続）」です。
「いちいちドアを閉めて帰る必要ないよね？次の依頼が来るまで、そこに座って待っててよ！」という考え方です。

これが実現すると、こうなります。

1. 接続： 挨拶をして、ドアを開けっ放しにする。
2. 要求/応答： 「画像ちょうだい」「はいよ」「次のアイコンも」「はいよ」と、1つのドアを通って次々と荷物をやり取りする。
3. 切断： 十分なやり取りが終わったら、最後にドアを閉める。

これだけで、コネクション確立にかかる「3ウェイ・ハンドシェイク（通信の握手）」という重い作業を何度も繰り返さなくて済むようになります。これが、現代のWeb高速化の基礎なのです。

しかし、この「居座る」仕組みには、サーバー管理者にとって悩ましい問題があります。それは「いつまで待てばいいのか？」という点です。

ずっとドアを開けっ放しにしていると、サーバーは「いつか来るかもしれない誰か」のために空き部屋を確保し続けなければなりません。これが積み重なると、サーバーのメモリやCPUがパンクしてしまいます。

そこで、「タイムアウト」というルールを設けます。例えば、NginxというWebサーバーで設定する場合、こんな風に書きます。

Nginxの設定例
http {
# 接続を保持する時間（5秒間何も無ければ閉める）
keepalive_timeout 5s;

# 1つの接続で処理できる最大リクエスト数
keepalive_requests 1000;
}

`keepalive_timeout 5s;`：5秒間、お客さんから何も注文が来なかったら「帰ってください！」とドアを閉めます。
`keepalive_requests 1000;`：1000回やり取りしたら、一度接続をリセットします（ずっと使い回すとメモリが溜まる可能性があるため）。

初学者のうちは、「とりあえずKeep-Aliveはオンにしておけば速くなるんでしょ？」と考えがちです。しかし、実務では「トラフィックとのバランス」が全てです。

「何秒に設定するのが正解？」という質問に、正解はありません。「あなたのサイトには、どれくらいの頻度でお客さんがやってくるのか？」というデータを見ながら、この数値を調整していくことこそ、インフラアーキテクトの醍醐味なのです。

HTTP/1.1のKeep-Aliveは、単なる通信設定ではありません。「通信相手を待たせないための、サーバーからのおもてなし」です。

もし今度、Webブラウザのデベロッパーツールを開く機会があったら、ぜひ「Network」タブを見てみてください。たくさんのファイルが同じコネクションを使ってダウンロードされている様子が見えるはずです。その裏側で、郵便屋さんが汗をかきながら、ドアの前で次の荷物を待っている姿を想像してみてくださいね。

ネットワークを「物理的な配線の塊」ではなく、「流れるデータと、それを待つサーバーの心」として捉えられるようになれば、あなたも立派なエンジニアの仲間入りです！

それでは、また次の深いお話でお会いしましょう。