Robin Marx氏の論文「Resource Multiplexing and Prioritization in HTTP/2 over TCP and HTTP/3 over QUIC 」の1章を読んだメモ。
https://h3.edm.uhasselt.be/ からダウンロードできます。いずれちゃんと読んでqiitaにまとめたい。
Introductionでは、HTTP/1.1の時代の課題から、HTTP/2が出てきた背景、HTTP/2の課題、QUIC/HTTP3が出てきた経緯、などが紹介されていました。歴史的な経緯を知るのにはいいのかも？
HTTPは、ここ数年で2015年のHTTP/2の標準化からほぼ最終段階にあるHTTP/3の標準化まで劇的な変化を5年の間に経験している 標準化が進んだ背景にはパフォーマンスとセキュリティがある。この論文ではパフォーマンスの問題に着眼する。
HTTP/1.1 1つのリソースしかリクエストできない。 そのワークアラウンドとして、ブラウザでは6つのコネクションを並列に開けるようにした。リソースが複数のドメインに分散していると、30コネクション必要になってしまう場合もあった。ページのロードは速くなったが、TCPコネクション事にメモリと処理が必要になるので効率は悪くなった。 更に、帯域の問題も発生した。それぞれの接続が帯域を争っている状態になる。TCPの輻輳制御はコネクションに行われる。パケットロスがバックオフシグナルになる。このような巨大な並列性がパケットロス率の上昇につながり、他のTCP接続を使うものとの間の問題が発生する。
そのような状況の中で、HTTP/2のゴールは、ウェブページのリソースを1つのTCPコネクションの下で多重化することだった。HTTP2では、リソースのペイロードを小さいチャンクに分割し識別子を付けて異なるリソースを1つのコネクション上でインターリーブすることだった。 これは、HTTP/1.1のHoLブロッキングを解決したが、新しい問題を発生させた。
それは、どのようにリソースを多重化するのか、そして、それらを一つのコネクション上でどのようにスケジューリングするかである。 これはリソースによるJSやCSSは速くダウンロードする必要がある。これらは多重化されずに送ったほうが良い。 HTMLやインクリメンタルに処理できる画像などは他のデータにインターリーブされていてもよい。 これらのリソースの優先度を設定することが、ウェブページのロードで良いパフォーマンスを得るためのキーである。 ブラウザに最大限の柔軟性を許すために、H2は複雑な優先度制御のシステムを含んでいる。
実用上、ブラウザやサーバにとって個の優先度制御は複雑で使うのが難しいことが判明している。いくつかの実装のみがそのポテンシャルをするに生かしていて、他の実装は部分的な最適化にとどまっておりページロード時間を逆に伸ばしてしまっている。 更に、一つのTCPコネクションを使うことで、TCP自身がHoLブロッキングを起こすことを表面化させた。 TCPは信頼性があり厳密に順序を守るプロトコルなので、一つのパケットロスでさえそのあとにあるほかのパケットをブロックしてしまい、再送を待つことになる。 これはH2にとっては効率的ではなかった。なぜなら、ブロックされたパケットが他のH2のリソースを含んでいて、そのリソースはロスしたパケットの再送を待たなくてもブラウザにとって使えるデータということがあるから。
TCPのHoLブロッキングを解決するのが、QUICを開発した理由の一つである。 TCPはペイロードを一つの連続したデータとして扱うが、QUICは複数の完全に独立したバイトストリームとして扱う。 なので、QUICは、信頼性と順番保証をストリーム毎に行う。つまり、TCPのようにグローバルなコネクションに紐づけられていないのです。 表向きはTCPのトランスポートレイヤーレベルのHoLブロッキングを解決しているが、実際にはどのくらいのアドバンテージがあるかはや、またすべての状況でその条件が満たされるかはクリアではない。 QUICがTCPの1ストリームのモデルから離れたほかの結果、TCPの振る舞いに依存しているいくつかのアプリケーションレイヤーのプロトコルが難しい、または困難になった。 キーとなる例は、H2である。これは直感的にQUICにマッピングする方法がなかった。その結果、H3という新しいプロトコルが開発された。 H3は高レベルの特徴はH2のものを保持しているが、HTTPヘッダー圧縮、サーバープッシュ、リソース優先度などが、実質的にQUICの新しいスペックに対応するためにリワークされている。 これらの新しいプロトコルは、パフォーマンスやベストプラクティスの観点で答えのない問題につながっている。
この論文では、過去のHTTP/2とHTTP/3の優先度制御に関する論文を下地にしたものと、QUICの新しい評価について扱う。 QUICとHTTP/3は、概念的には紐づけられているが、本質的には分離したプロトコルである。だから、最初に、それぞれについて独立に議論しその後、それらの発見を合わせて議論を行う。 Section2では、QUICの10の異なる実装の多重化とデータの再送を評価する。新しいプロトコルのオプションはスタックによって大きな違いがあることを発見した。 Section3では、QUICのHoLブロッキングの振る舞いに関する懸念について述べる。 QUICはTCPに対して明確な利点があることが分かった。しかし、それは、リソースの多重化のやり方に大きく依存している。 Section4とSection5では、著者の前の研究のアプリケーションレイヤーの結果をより深く考察する。 H2の優先度制御の設定と、なぜそれがH3で変わったのか議論する。その後、11の異なるH3の優先度制御の方法を42のウェブページに対してテストする。再び、最適な方法はコンテキストに依存することを示す。 これらの考察をQUICとHTTP/3に適用し、前の研究での結果がH3の優先度制御のアプローチの劇的な変化を始めるのを助けたかについて議論する。 すべてのソースコード、結果、可視化は、https://h3.edm.uhasselt.be で利用可能である。
