HTTPの通信を辞書で圧縮する提案について

HTTP 雑

現在 ChromeではHTTPの通信をBrotliの辞書で圧縮する『Feature: Compression dictionary transport with Shared Brotli』という仕組みの開発が進められています。

この仕組は、来週開催されるIETF 116のサイドミーティングでも議論が行われる予定になっています。

なので、軽くその仕組について予習をしておく。仕組みについて説明したドキュメントはこれ
github.com

Compression dictionary transport

基本的なアイデアとしては、サーバからBrotliの辞書データを提供して、以降のHTTP通信では(使える場合は)その辞書を活用してHTTPレスポンスを圧縮する (辞書データは他のサイトとは共有されない。Pathに合わせて複数の辞書を使い分けできるようになっている)

辞書データとしては、大きく2種類のユースケースがある (圧縮/解凍の利用のながれは一緒)

  • 普通にダウンロードしたJSファイルやCSSファイルをそのまま次回以降の辞書データとして活用する (jsやcssの一部変更があった場合に、ダウンロードし直す際に大きな圧縮効果を発揮する)
  • Linkタグで辞書データを指示し、使わせる

例

辞書データとしての保持

ファイルを取得する際に、取得したリソースを今後辞書データとして保持するまでの流れを説明します。
今回は、example.comのページからstatic.example.comのjsファイルを取得する流れで説明します。


  • クライアントは、このCompression dictionary transportに対応している場合、Accept-Encodingにsbrを追加してリクエストを送ります
  • サーバは
    • bikeshed-use-as-dictionaryとしてこの辞書を適応するPathの範囲を通知します (ヘッダ名は仮置きとなっている)
    • このやり取りではCORSが必須になるため、Access-Control-Allow-Originを付けます
    • Varyでこのキャッシュキーとして辞書データが依存することを通知する
  • クライアントは、レスポンスを受け取ったらこのデータを辞書データとして保持する

Linkタグで辞書データを読み込むときも概ね同じ流れになります。

辞書データの活用

次に、先の例で保持した辞書データを活用する流れを説明します。

  • クライアントは、辞書データを適応するPathに適合するリクエストを送る際、辞書を持っていることをsec-bikeshed-available-dictionaryヘッダで通知します。
  • サーバは、クライアントが持つ辞書を使って圧縮できる場合は圧縮します。このときヘッダに「Content-Encoding: sbr」が付きます (該当の辞書データがない場合は普通に圧縮する）。

圧縮効果やセキュリティなど

圧縮効果についてリサーチが進められています。
https://github.com/yoavweiss/compression-dictionary-transport/blob/main/examples.md
各サイトのJSファイルなどが大きく圧縮できる事がシミュレートされています。

また、セキュリティについてもCRIMEやBREACHといった圧縮効率から機密データを推測する攻撃が頭をよぎります。そのため、ユーザ固有の機密データが辞書データに含まれないようにしなければなりません。
https://github.com/yoavweiss/compression-dictionary-transport#risks