「HTTP/3 ってもう普通に使われてるの？」
Web で当たり前に使われている HTTP プロトコル。実は1.0 / 1.1 / 2 / 3 と複数バージョンが並列で動いています。Cloudflare や Google のサイトを Chrome の DevTools で見ると、もう HTTP/3 で通信していることが多いはずです。
この記事では、各バージョンが何を改善してきたのか、初学者向けに整理します。
HTTP/1.0（1996年）— 1リクエスト1接続
最初期の HTTP は「リクエストごとに TCP 接続を張って、レスポンスを受けたら切る」という素朴な設計でした。
当時の Web ページは画像数枚程度だったので問題なかったのですが、画像 30 枚のページを開くと TCP ハンドシェイク 30 回 + TLS 30 回...と、待ち時間ばかりが累積する欠点がありました。
HTTP/1.1（1997年）— Keep-Alive で接続を再利用
HTTP/1.1 で追加された目玉が Keep-Alive（永続接続）。1 つの TCP 接続を再利用して複数のリクエスト/レスポンスを順番に送れるようになりました。
他にも Host ヘッダー（バーチャルホスト対応）、Range（部分ダウンロード）、チャンク転送など、現代の HTTP 機能の多くは 1.1 で追加されました。
HTTP/1.1 の限界: Head-of-Line Blocking
Keep-Alive で接続を再利用しても、同じ TCP 接続上ではリクエストが順番待ちになります。重い画像 1 枚の取得が終わるまで、後続の軽い CSS が待たされる現象が起きます。これが Head-of-Line Blocking（HoL Blocking）です。
ブラウザは「同一ドメインに対して 6 接続まで並列」する回避策を取りましたが、本質的な解決ではありませんでした。
HTTP/2（2015年）— 多重化とヘッダー圧縮
HTTP/2 の最大の改善は 多重化（multiplexing）。1 つの TCP 接続上で複数のリクエストを同時並行で流せるようになりました。
HTTP/1.1: req1 ──→ res1 ──→ req2 ──→ res2 ──→ req3 ──→ res3
HTTP/2: req1 + req2 + req3 並行送信
res1 / res2 / res3 並行受信他の改善：
- HPACK によるヘッダー圧縮: 同じヘッダーを毎回送らない。Cookie が長いサービスで効果大
- バイナリプロトコル化: テキストではなくバイナリフレームに。パースが速い
- Server Push（後に廃止傾向）: サーバーが先回りしてリソースを送る
- 必須 TLS: 主要ブラウザの実装は HTTPS のみ
HTTP/2 の弱点: TCP 層の HoL Blocking
HTTP/2 はアプリケーション層の HoL Blocking は解決しましたが、下の TCP 層には残っていました。1 つでもパケットロスがあると、TCP は「順番通りに届けるため」全体を待たせるので、多重化のメリットが減ります。Wi-Fi や 4G/5G の不安定な回線で顕著です。
HTTP/3（2022年）— TCP を捨てて UDP の上で動く
HTTP/3 は思い切ってTCP ではなく UDP の上に「QUIC」という新プロトコルを構築し、その上で動くように設計されました。
HTTP/2: HTTP / TLS 1.3 / TCP / IP
HTTP/3: HTTP / QUIC (TLS 1.3 込) / UDP / IPQUIC の利点：
- TCP HoL Blocking がない: ストリームごとに独立して再送
- 0-RTT 接続再開: 過去に接続したサーバーには即データ送信可能
- TLS 1.3 が組み込み: 暗号化と接続確立が一体化
- コネクションマイグレーション: Wi-Fi → モバイル切替時もコネクション維持（IP/Port 変わってもコネクション ID で識別）
各バージョンの比較
| 項目 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 下位プロトコル | TCP | TCP + TLS | UDP + QUIC（TLS1.3込） |
| 多重化 | × | ○ | ○（TCP HoL なし） |
| ヘッダー圧縮 | × | ○ HPACK | ○ QPACK |
| 形式 | テキスト | バイナリ | バイナリ |
| 暗号化 | 任意 | 必須（実装上） | 必須（仕様上） |
| 接続確立 RTT | 1 + TLS 2 | 1 + TLS 1 | 1（再接続は 0） |
どれが使われているか
ブラウザは複数バージョンを話せて、サーバー側の対応に合わせて自動選択します（Alt-Svc ヘッダーで HTTP/3 への昇格を提案する仕組み等）。Chrome の DevTools の Network タブで Protocol 列を表示すると、各リソースが何で読まれたか確認できます。
現状（2026 年）：
- 大手サイト（Google / Facebook / Cloudflare 配下）: HTTP/3 がデフォルト
- 普通の HTTPS サイト: HTTP/2 が主流
- 内部 API・古いサイト: HTTP/1.1 も現役
- HTTP/1.0 はほぼ絶滅
セキュリティ視点
- HTTP/2/3 は事実上 TLS 必須。HTTP/1.1 と比べて自動的に最低限の暗号化が担保される
- HTTP/3 は UDP ベースなので、ファイアウォールで UDP/443 を塞いでいると使えない。一部の社内 LAN では HTTP/2 にフォールバック
- QUIC は途中経路から中身が見えにくい: 既存の中間装置（SSL Inspection 装置等）が対応していないと監査・フィルタリングが難しくなる
おわりに
HTTP のバージョン進化は「いかに遅延を減らすか」の歴史でもあります。1.1 で接続再利用、2 で多重化、3 で TCP 制約からの解放と、毎回大きな改善を重ねてきました。
Web 開発者として API を作るときは、サーバー（Nginx / CDN）が HTTP/2 / HTTP/3 を有効化されているか一度確認してみると、無料でユーザー体験を向上できます。