| この記事の要点 |
|
概要
HTTP/3 は、HTTP の第 3 世代バージョンで、最大の特徴は通信の土台を従来の TCP から QUIC という UDP ベースの新しいトランスポートへ置き換えた点です (2022 年に RFC 9114 として標準化)。HTTP/2 が「TCP の上で多重化を頑張る」設計だったのに対し、HTTP/3 は「TCP そのものの限界」に踏み込み、トランスポートから作り直しました。これにより、特にモバイルや不安定な回線での体感速度・接続の粘り強さが改善されます。親セクションは Web通信プロトコル です。
仕組み
HTTP/3 を理解する鍵は、土台の QUIC が何をしているかです。QUIC は UDP の上に、本来 TCP が担っていた機能 (信頼性のある順序通り配送、再送、輻輳制御) を、暗号化 (TLS 1.3) と多重化ごと再実装したトランスポートです。
- ヘッドオブラインブロッキングの解消: TCP は 1 本のバイト列なので、途中のパケットが 1 つ落ちると後続すべてが待たされます。QUIC はストリームごとに独立して順序保証するため、あるストリームのパケットロスが他のストリームを止めません。
- 高速な接続確立: QUIC は TLS 1.3 を統合しており、接続と暗号化の握手をまとめて行います。初回でも 1-RTT、再接続時は 0-RTT で、待ち時間を短縮できます。
- コネクション移行: 接続を IP アドレスではなく「コネクション ID」で識別するため、スマホが Wi-Fi からモバイル回線へ切り替わって IP が変わっても、同じ接続を維持できます。
ブラウザは最初 HTTP/2 等で接続し、レスポンスの Alt-Svc ヘッダでサーバが HTTP/3 (h3) に対応していることを知ると、以降の通信を QUIC に切り替えます。
実用例
HTTP/3 対応版の curl があれば --http3 で接続を試せます。サーバ側が Alt-Svc で h3 を広告しているかも確認ポイントです。
# HTTP/3 でリクエスト (HTTP/3 対応 curl が必要)
curl -I --http3 https://example.com/
# 出力例:
# HTTP/3 200
# サーバが HTTP/3 を広告しているか (Alt-Svc ヘッダ) を確認
curl -sI https://example.com/ | grep -i alt-svc
# 例: alt-svc: h3=":443"; ma=86400
# UDP/443 が通る必要があるため、経路で UDP が許可されているか確認
# (HTTP/3 は UDP ベース。途中の FW が UDP/443 を塞ぐと h3 が使えない)
sudo ss -ulnp 'sport = :443'
ブラウザの開発者ツールでは Protocol 列が h3 と表示されれば HTTP/3 で通信しています。最初の数リクエストは h2 で、その後 h3 に切り替わるのが典型です。
主な用途
- モバイル・不安定回線での高速化: パケットロスや回線切り替えが多い環境で、接続を維持しつつ速度を保つ。
- 大規模 Web サービス: 動画配信・SNS など、世界中の多様な回線からアクセスされるサービスで採用が進む。
- 低遅延が要るアプリ: 0-RTT 再接続で初回表示やリクエスト往復を短縮する。
- CDN 経由配信: 主要 CDN が HTTP/3 をサポートし、エッジでの高速配信に使われる。
HTTP/2 との比較
| 項目 | HTTP/2 | HTTP/3 |
|---|---|---|
| トランスポート | TCP | QUIC (UDP ベース) |
| HOL ブロッキング | TCP レベルで発生 | 解消 (ストリーム独立) |
| 暗号化 | TLS を別途 | TLS 1.3 を統合 |
| 接続確立 | TCP+TLS で複数 RTT | 1-RTT / 再接続 0-RTT |
| 回線切替時 | 接続が切れる | コネクション移行で維持 |
| ALPN 識別子 | h2 | h3 |
注意点
- UDP が前提: HTTP/3 は UDP/443 を使う。途中のファイアウォールやロードバランサが UDP を塞いだり未対応だと h3 が使えず HTTP/2 にフォールバックする。
- 0-RTT の再送リスク: 0-RTT で送るデータはリプレイ攻撃の余地があるため、副作用のある操作 (決済など) には使わない設計が必要。
- 運用・デバッグの難しさ: 暗号化が統合され UDP ベースのため、従来の TCP 前提のツールやパケット解析がそのままでは使いにくい。
- 必ず速くなるわけではない: 良好な有線回線では HTTP/2 との差は小さい。効果が大きいのは損失・遅延・回線切替が多い環境。
関連リンク
子ページ
子ページはありません
人気ページ
- 1 Eclipseで「サーバーに追加または除去できるリソースがありません。」の原因と対処法
- 2 tomcat の起動 / 停止ログと catalina.log・catalina.out の違い
- 3 JavaScript で base URL を取得する方法|window.location.origin
- 4 YouTube Data API v3 エラー一覧|403・400・404 の原因と対処
- 5 Laravel エラー一覧|500/Blade/DB 接続/ルーティングの代表エラー
- 6 3Dグラフィックスとは|モデリング/レンダリング/主要ソフトウェア (Blender / Maya)
- 7 Spring Frameworkのアノテーション一覧
- 8 【Spring】@Valueアノテーションとは
- 9 CATALINA_HOME の確認方法 (Linux / Mac)
- 10 【Spring】@Autowiredアノテーションとは
最近更新/作成されたページ
- Git pushした変更の取消し|revert・履歴変更と保護の注意点 2026-10-15 23:49:01
- Gitでローカルを戻す前に|reset・restoreの違いと退避範囲 2026-10-15 23:49:01
- Git rebaseの使い方|対象範囲・競合解決・pushの判断 2026-10-15 22:50:59
- Git pullの使い方|取込み先・ff-only・競合とstashの注意点 2026-10-15 22:50:59
- Git pushの使い方|送信先・タグ・force-with-leaseの条件 2026-10-15 22:12:47
- Git remoteの設定・確認・削除|SSH URLとfetch/pushの違い 2026-10-15 22:12:47
- Gitリモートリポジトリの作成|初回push・既存履歴・mirrorの注意 2026-10-15 15:48:16
- Gitのuser.name・user.email設定|local/global・確認と過去履歴の注意 2026-10-15 15:30:07
- LinuxにGitをインストール|配布元・初期設定・TLSと認証の確認 2026-10-15 15:30:06
- Git導入と初回push|Linuxサーバー・Windows/macOS・SSH設定 2026-10-15 14:51:54
- Db2のCREATE INDEX|索引定義・INCLUDEと実行計画の確認 2026-10-15 14:10:22
- Db2の自動採番|IDENTITY・ID取得とRESTARTの注意点 2026-10-15 14:10:22
- 【DB2】特定スキーマの全テーブルの全カラム情報を取得する方法 2026-10-15 13:53:15
- Db2のシーケンスとIDENTITYの違い|採番とカタログの確認SQL 2026-10-15 13:53:15
- Db2で複数カラムをUPDATEする方法|SET・WHEREと更新前の値 2026-10-15 13:53:15