RFC9218: Extensible Prioritization Scheme for HTTP をまとめてみた。

QUIC RFC network internet-draft

6月7日 2日前にHTTP/3 をはじめHTTP関連のRFCがHTTP wgよりたくさん発行された。

そのうち 新しいプライオリティ制御方式がRFC9218として標準化されたためまとめた。

www.rfc-editor.org

プライオリティ制御の必要性

  • HTTP/2 , HTTP/3 は、1 つの接続におけるリクエストとレスポンスの多重化が可能
  • 通信をより柔軟・効率的に行う為に各リクエストに優先順位をつけたい
  • 例: 
    • ブラウザが多重化によりCSSと画像のリクエストを同時に送る
    • レスポンスはレンダリングを開始するのに必要なCSSの優先度を上げて欲しい

↓上手なプライオリティ制御が大事というRobin Marxさんの図

引用元: https://h3.edm.uhasselt.be/

RFC7540のストリーム優先度との関係

RFC7540のストリーム プライオリティ制御を置き換える理由

もともと rfc7540 HTTP/2 の section 5.3で stream priority の説明をしている。リクエストの依存関係(dependency)と重さ(weight)で優先度を管理する方式をもちいる。

引用元: https://speakerdeck.com/summerwind/2-prioritization?slide=4

しかし仕様が複雑すぎたために広く実装されず、CDNの実装もbugが多かったとのこと。

つまりRFC7540のプライオリティ制御は失敗だったと言えるでしょう。

github.com

 

RFC9218では、よりシンプルで制約が多く、解釈を必要とせず、バリエーションも少ないシグナリングを記述することでより簡単に優先度制御をできる様にしています。

 

RFC7540との互換性

RFC9113 HTTP/2 よりRFC7540のプライオリティ制御はdeprecatedとなった。

相互運用性のための互換性は残してあります。

The description of frame fields and some of the mandatory handling is retained to ensure that implementations of this document remain interoperable with implementations that use the priority signaling described in RFC 7540.

from: RFC 9113: HTTP/2

SETTINGS_NO_RFC7540_PRIORITIES によってRFC9218に従うエンドポイントは相手に RFC7540のHTTP/2 プライオリティシグナルを使用しないことを通知します。

ただしクライアントはサーバからSETTINGSフレームをもらうまではサーバがHTTP/2 プライオリティシグナルを無視するかわからないため、クライアントはHTTP/2 プライオリティシグナル と このRFC9218で定められるprioritization schemeの両方を送ることが推奨される(SHOULD)。

 

Priority Parameters (section4)

  • Urgency(緊急度) と Incremental (逐次処理可能か) の二つの値を送る。
  • RFC7540よりシンプルなアプローチ
  • リクエストとリスポンスどちらにも含まれることがある。
  • ASCII text
  • encoded using Structured Fields
  • HTTP/2 に存在したStream Dependency (依存関係) は完全に廃止。
  • サーバがこれに従ってスケジュールを組むことは RECOMMENDED

Urgency (緊急度)

0 (優先度最大) から7 (優先度最低) までの整数値をとる。 (デフォルト3)

urgency の 高い順に レスポンスをサーバに返して欲しい。

 

最も低い緊急度レベル(7)は、ソフトウェアアップデートの配信のような バックグラウンドタスクのために予約されている。この緊急度レベルは、ユーザーとの対話に影響を与える応答を取得するために 使用されるべきではない(SHOULD NOT)。

 

例: urgencyを 0 に設定して CSS ファイルを要求したもの。

:method = GET
:scheme = https
:authority = example.net
:path = /style.css
priority = u=0

 

Incremental (逐次処理可能か)

ブール値でデフォルト値は false(0)

false(0) に設定して複数同時リクエストを行う場合

  • クライアントは応答を受け取りながら処理できない
  • サーバは同じ緊急度を持つ非インクリメンタルな応答を一つずつ送る。

true(1) に設定して複数同時リクエストを行う場合

  • サーバは同じurgencyを持つリクエストを同時並行に送る。
  • 帯域を分け合うためそれぞれの応答が完了するまでに時間がかかる。
  • 複数の部分的な応答 がクライアントに何らかの価値を提供できる場合有用。

例: JPEGファイルのリクエストを、urgencyパラメータを5に、incrementalパラメータをtrueに設定したもの。

:method = GET
:scheme = https
:authority = example.net
:path = /image.jpg
priority = u=5, i

 

Reprioritization 優先度の変更 (section6)

クライアントがリクエストを送った後、応答の優先度を変更する必要がある時にPRIORITY_UPDATE frameを送ってurgencyパラメータを変更する。

 

例 : JavaScriptのプリフェッチ

  • urgency パラメータを u=7 (background) に設定したプリフェッチリクエストを発行
  • プリフェッチの進行中にユーザーが新しい JavaScript ファイルを参照するページに移動
  • ブラウザは Priority Field Value を u=0 に設定した優先度の変更シグナルを送信

 

複数PRIORITY_UPDATE frameが届いた場合サーバは最新の情報を用いる。

  • HTTP/3では 順番は保証されないためメインよりupdateが先に到着する場合もある。

 

 

PRIORITY_UPDATE frame (Section7)

HTTP/2 ではストリーム ID を指定するのに対し、HTTP/3 では追加で type としてリクエストス トリームなのか、プッシュストリームなのかを指定します。

 

HTTP RFC Publication Study で話しました。

RFCが発行された3日以内に発行されたRFCについて話そうという勉強会に参加させていただきました。自分は7分だけ喋りました。他の人たちはとても長いRFCをdraftの段階から追っていてすごいなと思うとともに自分もこれからもっとRFCとかdraftとか読んでいきたいなとおもいました。

www.youtube.com

 

 

色んな参考サイト

 

kazuho さんが 2019年にhttp wg に送った draft書きましたメール。

lists.w3.org

lists.w3.org

 

http wg adoptionまでの道のりが書かれているLucas先生のブログ

blog.cloudflare.com

 

robin marx 先生

 

 

datatracker.ietf.org

datatracker.ietf.org

datatracker.ietf.org

 

asnokaze.hatenablog.com