#はじめに
「HTTP/2に対応しました！」——こんなアナウンスを見たことがあるかもしれません。でも、具体的に何が変わるのでしょうか？
HTTP/1.1は1997年に策定され、長年Webを支えてきました。しかし、Webページが複雑化し、読み込むリソースが増えるにつれ、HTTP/1.1の限界が見えてきました。HTTP/2とHTTP/3は、この問題を解決するために生まれた新しいプロトコルです。
この記事を読むと、以下のことができるようになります：
- HTTP/1.1の問題点を理解できる
- HTTP/2の多重化やヘッダー圧縮がなぜ速いのかがわかる
- HTTP/3とQUICの違いを理解できる
- DevToolsでプロトコルバージョンを確認できる
#HTTP/1.1の問題点
#1. Head-of-Line Blocking（HoL Blocking）
HTTP/1.1では、1つのTCP接続で一度に処理できるリクエストは1つだけです。
[リクエスト1] → [レスポンス1] → [リクエスト2] → [レスポンス2] → ...3つ目のリクエストは、1つ目と2つ目の完了を待たなければなりません。これを Head-of-Line Blocking（HoL Blocking） と呼びます。
#2. 複数接続のオーバーヘッド
HoL Blockingを回避するため、ブラウザは1つのサーバーに対して複数のTCP接続を開きます（通常6本）。しかし、各接続にはハンドシェイクのコストがかかります。
接続1: [CSS]
接続2: [JS]
接続3: [画像1]
接続4: [画像2]
接続5: [画像3]
接続6: [画像4]#3. ヘッダーの冗長性
HTTP/1.1では、リクエストごとに同じヘッダー（Cookie、User-Agentなど）を毎回送信します。
# リクエスト1
Cookie: session=abc123; user_pref=dark
User-Agent: Mozilla/5.0 ...
# リクエスト2（同じヘッダーを再送信）
Cookie: session=abc123; user_pref=dark
User-Agent: Mozilla/5.0 ...これらのヘッダーは圧縮されないため、帯域を無駄に消費します。
#HTTP/2の特徴
HTTP/2は2015年に標準化され、HTTP/1.1の問題を解決するために設計されました。
#1. 多重化（Multiplexing）
HTTP/2では、1つのTCP接続で複数のリクエスト/レスポンスを同時に処理できます。
┌──────────────────────────────────┐
│ 1つのTCP接続 │
│ │
│ [リクエスト1] ─────────────→ │
│ [リクエスト2] ───────→ │
│ [リクエスト3] ─────────────────→ │
│ ←───────── [レスポンス2] │
│ ←─────────────── [レスポンス1] │
│ ←─────────────────── [レスポンス3] │
└──────────────────────────────────┘リクエストとレスポンスは「ストリーム」という単位で管理され、順番を待たずに並行して送受信できます。
#2. ヘッダー圧縮（HPACK）
HTTP/2はHPACKというアルゴリズムでヘッダーを圧縮します。
- 静的テーブル: よく使うヘッダー（
:method: GETなど）に番号を割り当て - 動的テーブル: 過去に送信したヘッダーを記憶し、差分のみ送信
これにより、ヘッダーサイズが大幅に削減されます。
#3. バイナリプロトコル
HTTP/1.1はテキストベースでしたが、HTTP/2はバイナリベースです。
# HTTP/1.1（テキスト）
GET /index.html HTTP/1.1
Host: example.com
# HTTP/2（バイナリフレーム）
[フレームヘッダー][ペイロード]バイナリ形式は解析が高速で、エラーが起きにくいという利点があります。
#4. サーバープッシュ
サーバーが、クライアントからのリクエストを待たずにリソースを送信できる機能です。
クライアント: GET /index.html
サーバー:
→ index.html
→ style.css（プッシュ）
→ script.js（プッシュ）HTMLを解析してからCSSをリクエストする前に、サーバーが先回りして送信できます。
ただし、キャッシュとの整合性の問題などから、実際にはあまり使われていません。Chromeは2022年にサーバープッシュのサポートを削除しました。
#5. ストリームの優先度
どのリソースを優先的に送信するかを指定できます。CSSやJSを画像より優先するなど、レンダリングに重要なリソースを先に送れます。
#HTTP/3の特徴
HTTP/3は2022年に標準化された最新のHTTPプロトコルです。
#TCPからQUICへ
HTTP/3の最大の特徴は、TCPの代わりにQUICを使用することです。
HTTP/1.1: HTTP/1.1 + TLS + TCP
HTTP/2: HTTP/2 + TLS + TCP
HTTP/3: HTTP/3 + QUIC（TLS 1.3内蔵）+ UDP#QUICとは
QUIC（Quick UDP Internet Connections） は、Googleが開発したトランスポートプロトコルです。UDPの上に構築され、以下の特徴があります：
#1. 接続確立の高速化
TCPは3ウェイハンドシェイク、TLSはさらに追加のやり取りが必要でした。QUICはこれらを統合し、1往復（場合によっては0往復）で接続を確立できます。
TCP + TLS 1.2: 3 RTT
TCP + TLS 1.3: 2 RTT
QUIC: 1 RTT（0-RTTも可能）#2. HoL Blockingの解消
HTTP/2はTCP上で動作するため、パケットロスが発生すると全ストリームが影響を受けます（TCP層でのHoL Blocking）。
QUICはストリームごとに独立しているため、1つのストリームでパケットロスが起きても、他のストリームは影響を受けません。
HTTP/2 over TCP:
パケットロス → 全ストリームが待機
HTTP/3 over QUIC:
パケットロス → 該当ストリームのみ再送待ち、他は継続#3. コネクションマイグレーション
QUICは接続をコネクションIDで識別するため、IPアドレスが変わっても接続を維持できます。
Wi-Fi → モバイル回線に切り替え → 接続継続これは、モバイルデバイスでネットワークが切り替わる場面で有効です。
#プロトコルの比較
| 特徴 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 多重化 | ❌ | ✅ | ✅ |
| ヘッダー圧縮 | ❌ | HPACK | QPACK |
| トランスポート | TCP | TCP | QUIC (UDP) |
| TLS | オプション | 実質必須 | 必須（内蔵） |
| HoL Blocking | あり | あり（TCP層） | なし |
| 接続確立 | 遅い | 遅い | 速い |
#DevToolsで確認してみよう
#プロトコルバージョンの確認
- DevToolsのNetworkタブを開く
- 列ヘッダーを右クリック → 「Protocol」にチェック
- 各リクエストのProtocol列を確認
表示される値：
http/1.1: HTTP/1.1h2: HTTP/2h3: HTTP/3
#HTTP/2の多重化を観察
- HTTP/2対応サイトにアクセス
- Networkタブで複数のリクエストを観察
- 「Waterfall」列で、リクエストが並行して処理されていることを確認
HTTP/1.1では階段状（順次処理）、HTTP/2では並列に処理されます。
#対応状況
#ブラウザサポート
- HTTP/2: すべての主要ブラウザが対応
- HTTP/3: Chrome、Firefox、Safari、Edgeが対応
#サーバーサポート
- HTTP/2: Nginx、Apache、Cloudflare、AWS CloudFrontなど
- HTTP/3: Cloudflare、Google Cloud、Fastlyなど
多くのCDNがHTTP/3に対応しているため、CDNを使用していれば自動的にHTTP/3の恩恵を受けられることがあります。
#まとめ
- HTTP/1.1の問題: HoL Blocking、複数接続のオーバーヘッド、ヘッダーの冗長性
- HTTP/2の改善: 多重化、ヘッダー圧縮、バイナリプロトコル
- HTTP/3の改善: QUICによる高速な接続確立、TCP層のHoL Blocking解消
- DevToolsでProtocol列からプロトコルバージョンを確認できる
#次のステップ
HTTP基礎モジュールはこれで完了です。HTTPの構造、ステータスコード、ヘッダー、HTTPS、そしてプロトコルの進化について学びました。
次のモジュールでは、Cookie・認証・セッションについて学びます。ステートレスなHTTPで、どのようにユーザーの状態を管理するのか——Cookieの仕組みから、セッション管理、JWT、OAuth 2.0まで、認証の基礎を身につけましょう。