【入門編】HTTP/1.1のConnection: keep-aliveとパイプライン処理 – HTTPプロトコル・通信規格実践ガイド

HTTPの「行列」を解消せよ！Keep-Aliveとパイプライン処理でWebを高速化する仕組み

こんにちは！ネットワークエンジニアの世界へようこそ。

普段何気なくWebサイトを見ているとき、ブラウザの裏側ではものすごい勢いで「やり取り」が行われています。今日は、Web通信の歴史の中でも、特に「効率化」の立役者となったHTTP/1.1の魔法についてお話ししましょう。

「ページを開くのが遅い」というイライラを解消するために、先人たちはどんな工夫を凝らしたのか。郵便配達の仕組みに例えて、一歩ずつ紐解いていきましょう！

—

HTTP/1.0の頃の通信は、実はとても非効率でした。例えるなら、「手紙を一通送るたびに、わざわざ郵便局を開けて、配達して、すぐに郵便局を閉める」というような状態です。

1. ブラウザ（あなた）がサーバー（郵便局）に「接続」する。
2. サーバーに「画像ちょうだい」と頼む。
3. サーバーが「はいどうぞ」と送る。
4. ここで接続を切断する。

Webページには画像やスタイルシートなど、たくさんのファイルが含まれていますよね。そのたびに「接続→送信→切断」を繰り返していたら、いくら速い回線でも時間がかかって仕方ありません。これが通信の大きな足かせとなっていました。

—

そこで登場したのが、HTTP/1.1の目玉機能である「Keep-Alive（キープアライブ）」です。「持続的接続」とも呼ばれます。

イメージは簡単です。「用事は一回じゃないんだから、郵便局の窓口を閉めずに開けたままにしておこうよ！」というアイデアです。

これだけで、接続にかかる無駄な待ち時間が劇的に減りました。現代のWebサイトがサクサク動くのは、この「開きっぱなし」のおかげなんです。

ブラウザとサーバーの会話では、こんなやり取りが行われています。

ブラウザからサーバーへの合図
GET /index.html HTTP/1.1
Host: example.com
Connection: keep-alive # 「終わっても接続を切らないでね！」という意思表示

—

Keep-Aliveで「窓口は開いたまま」になりました。しかし、まだ課題があります。それは「前の注文の答えが返ってくるまで、次の注文ができない」というルールです。

窓口で「カレーください」と言った後、カレーが出てくるまで「次のお茶ください」と言えないとしたら、待ち時間がもったいないですよね？

これを解決するのが「パイプライン処理」です。

これは、「答えを待たずに、注文書をどんどん窓口に投げ込む」というテクニックです。

サーバー側は、受け取った順に料理を並べて、準備ができたものから順番に返していきます。これによって、通信の効率は限界まで引き上げられました。

—

ここまで聞くと「最高じゃないか！」と思うかもしれませんが、実は現実世界のネットワークでは、パイプライン処理は「あまり使われていない」のが現状です。

なぜでしょうか？最大の理由は「ヘッド・オブ・ライン・ブロッキング（先頭の注文が詰まると、後ろも全部止まる問題）」です。

例えば、注文した「カレー」の調理にものすごく時間がかかっているとします。後ろの「お茶」はすぐに準備ができているのに、前のカレーが邪魔をして、お茶を渡すことができません。結果として、後続の全ての処理がストップしてしまうのです。

また、古いネットワーク機器（プロキシサーバーなど）がこの処理に対応しきれず、通信エラーを引き起こすことも多く、実務現場では慎重に扱う必要がありました。

—

HTTP/1.1のKeep-Aliveとパイプライン処理は、Webの高速化に向けた「最初の大きな挑戦」でした。

現在では、これらを進化させたHTTP/2やHTTP/3が主流となり、さらに賢い方法で通信が行われています。しかし、その根底にある「いかに効率よく情報を届けるか」という哲学は、このHTTP/1.1の時代から全く変わっていません。

まずは、お使いのブラウザの「開発者ツール（F12キー）」を開いてみてください。「ネットワーク」タブを見ると、Keep-Aliveで接続が維持されている様子が確認できるはずです。

ネットワークの仕組みを知れば、Webサイトを見る目が少しだけ変わるかもしれませんよ！それでは、また次の技術解説でお会いしましょう。