HTTP1.0/1.1/2/3の違いを分かりやすく

HTTPのセッションとストリームを「トンネルとトラック（ストリームの色分け）」に置き換えて勉強していきましょう。
HTTP/1.0 → HTTP/1.1 → HTTP/2 → HTTP/3 の違いを整理して見ていきましょう。

🛣️ 共通イメージ：「1本の道路（TCP接続）」と「トラック（HTTPリクエスト）」

• 道路（トンネル）：TCP接続
• トラック：HTTPリクエスト・レスポンス
• 荷物の色分け（赤・青・緑）：HTTP/2以降のストリームID（リクエスト識別）

🚗 HTTP/1.0：

「トラック1台ずつしかトンネルに入れない」

イメージ

┌───────────────┐
│ トンネル(TCP) │
└───────────────┘
   🚚(リクエスト1)
   ↑出たら閉じる
   🚚(リクエスト2)
   ↑出たらまた閉じる

説明

• リクエストごとにTCP接続を新規に作る。
• 1ページに画像が10個あれば、10回トンネルを掘る（＝10回TCP確立）。
• → トンネル掘る（3ウェイハンドシェイク）だけで時間がかかる。

問題点

• 接続確立コストが大きい
• 同時に1つのリクエストしか送れない

🚚 HTTP/1.1（Persistent Connection）：

「トンネルは1本のまま、トラックを何台も順番に通せるようになった」

イメージ

┌───────────────┐
│ トンネル(TCP) │
└───────────────┘
   🚚(リクエスト1)
   🚚(リクエスト2)
   🚚(リクエスト3)
   …

説明

• 一度トンネルを掘ったら（TCP接続確立したら）、閉じずに使い回す（Keep-Alive）。
• これでTCPの確立コストが削減。

でも問題発生：ヘッドオブラインブロッキング（HOLB）

• トラック（リクエスト）は1台ずつ順番にしか通れない。
• 先頭のトラックが渋滞（応答遅延）すると、後ろのトラックも動けない。
• これがHTTP/1.1のHOLB問題。

🚚(画像1:遅い)
🚚(画像2:早いけど待ち)
🚚(画像3:早いけど待ち)

🚛 HTTP/2（マルチプレクシング）：

「1本のトンネルの中で、トラックに色を付けて、混在して走らせる！」

イメージ

┌──────────────────┐
│ トンネル(TCP)   │
│ 🚚赤🚛青🚚赤🚜緑🚚青🚜緑 │ ← 順番に混ざって流れる
└──────────────────┘

説明

• トラック（HTTPリクエスト）をフレーム単位に細かく分ける。
• それぞれに「ストリームID（色）」を付ける。
• 同じトンネル内で、赤・青・緑のトラック（データ）を交互に流せる。

→ アプリ層的には「複数リクエストを同時に処理できる」ように見える！

しかし…

• トンネル（TCP）は1本。
• もしトンネル内で1つのパケットが落ちると、後続のデータが全部ストップ。
  → これがTCPレベルのHOLB。

🚚赤[欠損]🚛青🚜緑 → 青と緑は来てるけど、赤が復旧するまで渡せない

🚀 HTTP/3（QUIC：UDPベース）：

「トンネルをやめて、それぞれが自分専用のレーンを持つ」

イメージ

🚚赤 ────────────→
🚛青 ───────→
🚜緑 ─────────────→

説明

• TCPではなくUDP＋QUICを使う。
• QUICでは、ストリームごとに独立した再送制御ができる。
• 赤のトラックが事故っても、青と緑は自分のレーンで進める。

→ TCP時代のHOLB問題を完全に解消！

💡 まとめ表

🎯 重要ポイント（ネスペ試験で狙われる）

1. HTTP/1.1のHOLB問題
   • 1つのTCP接続上でリクエストを順次送るため、先頭の応答遅延が全体に影響する。
2. HTTP/2の改善
   • マルチプレクシングにより、論理的には並列化できるが、TCPの順序制御が根本的に残る。
3. HTTP/3の最終解決
   • UDPベースのQUICで、ストリームごとの独立再送を実現。真の並列処理が可能。

• HTTP/1.0：トンネルを毎回掘ってトラックを1台ずつ通す
• HTTP/1.1：トンネルは共通だが、トラックは順番待ち
• HTTP/2：トンネル内で色分けして混ぜて走らせる
• HTTP/3：トンネルをやめて、色ごとに独立した道路を持たせる