🪁
taisablog
HTTP3-Explained を読んで - QUIC HTTP3 まとめ
🛵

HTTP3-Explained を読んで - QUIC HTTP3 まとめ

きっかけ

月1で行っている Okachi.js という勉強会で下記ドキュメントを輪読したのでまとめておきます。また、まとめる上でいろんなサイトが参考になったので引用させてもらっています。

QUIC とは

QUICとは、UDPを用いて高速化しつつ、 TCPのような通信の信頼性を提供するトランスポートプロトコルです。 TCPにはない接続確立時間の最小化、通信経路やIPアドレスが切り替わったときの通信継続、 TLSによる暗号化、先行するコネクションの処理待ち(Head-of-Line Blocking)の回避など、 さまざまな機能が提供されており、RFC 9000を中核に、RFC 9001、9002 など、 複数のRFCによって標準化されています。 QUICは、2013年頃からGoogle社が同社のサービスを提供する際に、 高速化を目的として独自に使用されていました。 その仕様が標準化のため2016年IETFへ提案されました。 その後IETFでの議論によりさまざまな修正や機能追加が行われ、 多目的に利用できる新しいトランスポートプロトコルとして2021年に標準化されました。

https://www.nic.ad.jp/ja/basics/terms/quic.html

ブラウザサポート

macOS は 11 Big Sur 以上という微妙な制約があるものの、ほとんどの主要ブラウザがサポートしています。

image

https://caniuse.com/http3

従来のHTTPとHTTP/3の構成の違い

TCP ではなく、UDP 上で動くのが特徴で、UDP 自体は信頼性の高い転送プロトコルではないですが、UDP 上に信頼性をもたらすレイヤーを追加しているのが大きな特徴と言えます。

image

https://xtech.nikkei.com/atcl/nxt/mag/nnw/18/121900044/122000004/

なぜ UDP 上に作られたか

head-of-line ブロッキング問題

http1.1 → http2 → QUIC（http3）の改善

Http head-of-line ブロッキング問題

http1.1 → http2 で改善された問題

HTTP/2 は HTTP/1.1 における head-of-line ブロッキング問題 (クライアントは、次のリクエストを送信するために既存のリクエストのデータを取得し終わるまで待たなければならない問題) を解消しています。

詳しくは下記ページが分かりやすく参考になりました。

TCP head-of-line ブロッキング問題

http2 → QUIC（http3）で改善された問題

パケットロス率が上がるにつれて、HTTP/2 のパフォーマンスはますます低下します。 2 %のパケットロス (これはかなりひどいです、念のため。) があるネットワーク環境では、大抵の場合において HTTP/1 のほうがパフォーマンスが良くなることがテストで証明されています。 これは、HTTP/1 では通常6つまでの TCP コネクションを使ってパケットを送信するためです。つまり、パケットが損失した箇所があっても他のコネクションが止まることはないということです。TCPを使用する限り、この問題を解決することは簡単ではありません。

詳しくは下記ページが分かりやすく参考になりました。

プロトコルの硬直化

当時知られていなかった、新しい仕様の追加や振る舞いの変化があると、その機器にとっては不具合や不正といったリスクと見なされます。 このようなトラフィックは、単に捨てられたり、あるいはその機能を使用したくないと思うほど遅延させられたりします。 このような状況は「プロトコルの硬直化」と呼ばれます。

レイテンシの軽減

TCP 3way ハンドシェイク

TCP の場合 3way ハンドシェイクがあり、その後 TSL ハンドシェイクが行われます。

image

https://medium.com/@alysachan830/tcp-and-tls-handshake-what-happens-from-typing-in-a-url-to-displaying-a-website-part-2-243862438cd9

QUIC と TCP のハンドシェイク比較

QUIC の場合、TCP のようなハンドシェイクがないのでその分レイテンシが軽減できます。

image

https://eng-blog.iij.ad.jp/archives/11018

※ TCP Fast Open 問題

TLS 1.3

QUIC は TLS 1.3 を使うので、RTT（ラウンドトリップ回数）が少なくてすみます。

QUIC におけるトランスポートセキュリティには TLS 1.3 (RFC 8446) を使用しており、暗号化されない QUIC コネクションは一切ありません。 TLS 1.3 には従来の TLS と比較していくつか利点があります。 QUIC が TLS 1.3 を使用する主な理由は、1.3からはラウンドトリップ回数が少なくなるようにハンドシェイクに変更が加えられているためです。これにより、プロトコルの待ち時間を短縮することができます。 かつて Google が提案した QUIC では独自の暗号化技術を使用していました。

TSL 1.2 と TLS 1.3 のフルハンドシェイクの違い

image

https://www.a10networks.com/glossary/key-differences-between-tls-1-2-and-tls-1-3/

0-RTT ハンドシェイクと 1-RTT ハンドシェイク

加えて、0-RTT ハンドシェイクも可能となっています。

QUIC は新規コネクションのネゴシエート時間を短縮するため、0-RTT ハンドシェイクと 1-RTT ハンドシェイクを提供します。

フルハンドシェイクの場合 1-RTT、再接続の場合 0-RTT

image

https://blog.codavel.com/tls-1.3-the-new-security-king

※ Early Data サポート

QUIC の主な特徴まとめ

高信頼性のデータ転送

UDP は信頼性の高い転送プロトコルではありませんが、QUIC は UDP 上に信頼性をもたらすレイヤーを追加します。これはパケットの再送、輻輳制御、ペーシングおよび現在の TCP が持つこれら以外の機能を提供します。一方のエンドポイントが QUIC を用いて転送したデータは、コネクションが維持されている限り、遅かれ早かれ他方に届きます。

常にセキュア

QUIC は常にセキュアです。平文版のプロトコルが存在しないので、QUIC コネクションをネゴシエートすることは TLS 1.3 を用いて暗号化とセキュリティを行うことと同義です。(拡張性を損なうという意味での) 硬直化や他の種類のブロックと特別な処理を防ぐと同様に、QUIC は Web ユーザーが望んでいた HTTPS のセキュアなプロパティを全て備えています。

素早いハンドシェイク

QUIC は新規コネクションのネゴシエート時間を短縮するため、0-RTT ハンドシェイクと 1-RTT ハンドシェイクを提供します。TCP における 3-way ハンドシェイクと比較してみてください。加えて、QUIC はより多くのデータを処理するため、最初から "early data" をサポートしており、TCP Fast Open よりも簡単に利用できます。既存のコネクションが終了するのを待つことなく同じホストへ別のコネクションを接続できることが、ストリームのコンセプトとして挙げられています。

カーネルと CPU 負荷

Google と Facebook は QUIC を彼らの膨大なトラフィックに適用した場合、HTTP/2 over TLS に比べ約2倍の CPU が必要になると言っています。しかし、下記のような説明が含まれています。歴史的に多くの Linux の UDP スタックはこのような高速通信に利用されることを想定していなかったため、TCP スタックに比べて最適化がされていないTCP と TLS の負荷を軽減するハードウェアは存在しているが、UDP のものはほとんどない。基本的に QUIC 向けのものは存在していない。このような問題点がありますが、パフォーマンスと CPU の要求が将来的に改善されると信じています。

到着順序の保証

QUIC はストリーム内での到着順序を保証しますが、ストリーム間の順序を保証しません。

Http ヘッダー圧縮

HTTP/3 と呼ばれる HTTP レイヤーは HTTP に準拠したトランスポートを行います。HTTP ヘッダ圧縮では QPACK を利用しており、これは HTTP/2 における HPACK に似ています。 HPACK アルゴリズムはストリームが順番に届くことを前提としているため、修正せずに HTTP/3 で再利用することは不可能です。 これは QUIC の提供するストリームにおいては転送がばらばらに行われるためです。

Non-HTTP over QUIC

HTTP 以外のプロトコルを QUIC を使って通信するための対応は、QUIC のバージョン1が実際にリリースされるまで延期されました。

その他

  • Spin Bit
    • メーリングリストではすごい長い間議論がかわされていたらしい
  • QUIC には標準 API はない

ブラウザで HTTP3 の通信を見るには

輪読していたときは h3 が結構みれたのですが、書いているときはなかなかみつけられず

image

参考

動画

記事

FacebookXGitHub