TL;DR

2022 年に RFC 9114 で発表された HTTP の標準バージョン。QUIC プロトコルを土台にしている。

なぜ必要か

HTTP/2 では、TCP の制約による遅延やブロッキングが問題になっていた。たとえば HOL ブロッキングでは、送信側が受信側の確認応答を受け取るまで次のデータを送れない。

RFC 9114 によると、TCP の損失回復の仕組みは HTTP/2 の中の並列性を知らないので、パケットが 1 つ失われたり順序が入れ替わったりすると、影響を受けていないリクエストも含めてすべてが止まる。

仕組み

QUIC は UDP の上で通信するので、TCP より速く通信できる。QUIC は複数のストリームを独立して扱うので、HOL ブロッキングを避けられる。

UDP は TCP より信頼性が低いので、QUIC は次の機能を自分で持つ。

  • パケットロスが起きたら、そのストリームだけを再送する
  • シーケンス番号でデータの順序を保証する

RFC 9114 によると、HTTP/3 は HTTP のセマンティクスをそのままにして、トランスポートを QUIC に変えたものである。QUIC は、ストリームの多重化、ストリームごとのフロー制御、少ない遅延での接続確立を提供する。QUIC には TLS 1.3 が組み込まれており、HTTP/3 はデータの機密性と完全性の保護、通信相手の認証を QUIC に任せる。

関連

出典