HTTP/1.1の「行列」問題：なぜWebサイトはたまに「詰まる」のか？
こんにちは！ネットワークの世界へようこそ。今日は、Webブラウザでページを開くときに背後で起きている「ちょっとした渋滞」のお話です。
Webサイトを表示する際、ブラウザは裏側でサーバーに対して「この画像ちょうだい！」「次はCSSファイルちょうだい！」と何度もリクエストを送っています。このやり取りのルールである「HTTP/1.1」には、実は「Head-of-Line (HOL) ブロッキング」という、ちょっと困ったクセがあるんです。
「なんだか難しそうな名前だな…」と感じましたか？大丈夫、郵便配達に例えて、一緒に紐解いていきましょう！
—
郵便ポストに例えるHTTP/1.1の「パイプライン」
HTTP/1.1というルールは、一つの大きなパイプ（コネクション）を使って、複数の注文を順番に送る「パイプライン化」という仕組みを持っています。
これを「郵便配達」でイメージしてみてください。
1. あなたが郵便局（サーバー）に、手紙（リクエスト）を3通まとめて出しました。
2. 郵便局員は、届いた順番に処理を始めます。
3. しかし、一番前の手紙の処理がすごく時間がかかるものだったら？
一番前の手紙が、複雑な調査が必要でなかなか終わらないとします。すると、後ろの2通は、前の手紙が終わるまでずっと窓口のカウンターで待機させられてしまいますよね。これが「HOLブロッキング」の正体です。
前の処理が終わるまで、後ろの処理がどれだけ早く終わる内容であっても、物理的に動くことができない。これがHTTP/1.1でWebサイトの読み込みが重くなる原因の一つなんです。
—
なぜ「順番待ち」が起きてしまうのか？
HTTP/1.1の設計思想は「シンプルに、順番通りに」です。そのため、サーバーは「受け取った順番通りに結果を返さなければならない」というルールがあります。
もし、3番目のリクエストが先に終わったからといって、勝手にそれを返してしまうと、ブラウザ側が「あれ？順番が違うぞ？」と混乱してしまいます。だからこそ、一番前の行列が動かない限り、後ろは立ち往生するしかないのです。
—
現場で起きる現象を観察してみよう
実際にWebブラウザの開発者ツール（F12キーを押して「ネットワーク」タブを開いてみてください）を見ると、この現象が垣間見えます。
もし皆さんがサーバーのログや、簡単なPythonコードでこの挙動をシミュレートするとしたら、以下のようなイメージになります。
HTTPの処理を模した擬似的なコードです
requests = [“画像1”, “重い計算処理”, “画像2”]
for req in requests:
if req == “重い計算処理”:
print(“【時間待ち】前の処理が終わるまで、後ろの画像2は待機します…”)
# ここで処理がブロックされる（HOLブロッキング！）
else:
print(f”{req} を処理しました”)
このように、コード上でも「前の処理が終わるまで次に行けない」という制約が、そのままWebの表示速度に直結してしまうのです。
—
どうやって解決したの？
この「行列問題」を解決するために、エンジニアたちは様々な工夫をしてきました。
- ブラウザの工夫： 一つのパイプだけで待つのは効率が悪いので、同じサーバーに対して複数のパイプ（コネクション）を同時に開いて、「6つくらいの行列を同時に作る」という力技を使っていました。
- HTTP/2の登場： これが現在の主流です。HTTP/2では「多重化」という魔法のような技術が使われました。郵便配達に例えるなら、「手紙をバラバラに分解して、封筒に関係なく空いている隙間にどんどん詰め込んで届ける」というスタイルです。これなら、前の手紙が遅れていても、後ろの手紙が先に届くことができるので、行列は詰まりません。
—
最後に：インフラエンジニアの視点
HTTP/1.1はインターネットを支えてきた偉大な規格ですが、今回お話しした「HOLブロッキング」のような限界もありました。
ネットワークを学ぶ際、「なぜこの技術が使われているのか？」「このルールは何を制限してしまっているのか？」と疑問を持つことは、一流のエンジニアへの第一歩です。
まずは、皆さんが普段見ているWebサイトが、どのプロトコルで通信しているのか、開発者ツールの「プロトコル」列をぜひチェックしてみてください。「h2（HTTP/2）」になっているか、「http/1.1」になっているかを見るだけで、世界が少し違って見えてくるはずですよ！
次回は、この「行列問題」を根本から解決したHTTP/2の仕組みについて、もっと深く掘り下げていきましょう。それでは、また！
コメント