2.

HTTP/3 (QUIC) とは UDP ベースの低遅延 Web 通信 | ネットワーク入門

編集
この記事の要点
  • HTTP/3 は HTTP のトランスポートを TCP から UDP ベースの QUIC へ置き換えた最新世代の Web 通信プロトコル (RFC 9114)
  • QUIC は UDP 上に信頼性・順序保証・暗号化・多重化をまとめて実装したトランスポートで、TLS 1.3 が統合されている
  • TCP のヘッドオブラインブロッキングを解消し、あるストリームのパケットロスが他のストリームを待たせない
  • 接続確立が速く (0-RTT/1-RTT)、コネクション ID により Wi-Fi↔モバイル回線の切り替えでも接続を維持できる (コネクション移行)
  • ブラウザは Alt-Svc ヘッダで HTTP/3 の存在を知り、対応していれば h3 にアップグレードする

概要

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/2HTTP/3
トランスポートTCPQUIC (UDP ベース)
HOL ブロッキングTCP レベルで発生解消 (ストリーム独立)
暗号化TLS を別途TLS 1.3 を統合
接続確立TCP+TLS で複数 RTT1-RTT / 再接続 0-RTT
回線切替時接続が切れるコネクション移行で維持
ALPN 識別子h2h3

注意点

  • UDP が前提: HTTP/3 は UDP/443 を使う。途中のファイアウォールやロードバランサが UDP を塞いだり未対応だと h3 が使えず HTTP/2 にフォールバックする。
  • 0-RTT の再送リスク: 0-RTT で送るデータはリプレイ攻撃の余地があるため、副作用のある操作 (決済など) には使わない設計が必要。
  • 運用・デバッグの難しさ: 暗号化が統合され UDP ベースのため、従来の TCP 前提のツールやパケット解析がそのままでは使いにくい。
  • 必ず速くなるわけではない: 良好な有線回線では HTTP/2 との差は小さい。効果が大きいのは損失・遅延・回線切替が多い環境。

関連リンク

編集
Post Share
子ページ

子ページはありません

同階層のページ
  1. HTTP/2
  2. HTTP/3(QUIC)
  3. WebSocket
  4. gRPC
  5. WebRTC

最近更新/作成されたページ