Brotliとは
Brotli（ブロートリ）は、Web配信用途で高い圧縮率を狙って設計された可逆圧縮形式です。元のバイト列を完全に復元でき、HTTPではコンテンツ符号化名brとして使われます。
過去の列を参照するLZ77系の仕組み、ハフマン符号化、記号の文脈、よく使う語の組み込み辞書を組み合わせます。特にHTML、CSS、JavaScript等で辞書が役立ちます。
Brotliは「gzipより必ず何%小さい」という固定結果ではありません。入力、エンコーダーバージョン、品質、時間窓、速度要件で結果が変わるため、実データで比較します。
Brotliが組み合わせる仕組み
時間窓内で同じ並びを探し、距離と長さで表します。
一般語やWebで現れやすい断片を、変形指定と共に短く参照します。
直前の記号等から文脈を選び、偏りに合うコードを使います。
リテラル、長さ、距離等の文字集合を短いビット符号へします。
メタブロックでストリームを区切る
Brotliストリームはメタブロックの列として構成されます。圧縮ブロック、非圧縮ブロック、メタデータ用ブロック等があり、圧縮ブロックにはリテラルと複製命令、その符号表や文脈情報が入ります。
メタブロックはHTTPチャンクやファイルシステムブロックと同じ境界ではありません。ネットワークで分割して届いてもデコーダーはBrotliストリームの状態を保って処理します。
組み込み辞書は外部ファイルではない
Brotliの仕様には、よく使われる語の辞書が定義されています。デコーダーも同じ辞書を実装するため、通信ごとに辞書ファイルを別送する必要はありません。
辞書項目へ接頭辞・接尾辞や大文字化などの変換を適用できます。ただし任意の利用者辞書を自動学習して共有するという意味ではありません。
品質と時間窓
エンコーダーの品質を上げると、より広い探索や精密なモデルへ時間を使い、小さくなる可能性があります。展開速度への影響は圧縮時間ほど大きくないことが多い一方、結果は実装とデータで測ります。
広い時間窓は遠くの繰り返しを参照できますが、デコーダーメモリーも増えます。受信環境が許容する時間窓と、サーバーの圧縮CPU予算を決めます。
静的資産と動的応答
ビルド時に一度だけ作るCSS・JavaScript・SVG等は、高めの品質で事前圧縮し、元ファイルと共に保存できます。要求ごとに変わる応答は低めの品質やgzipを含め、総応答時間で選びます。
圧縮済み変種は元内容が変わるたび更新します。古い.brだけが残ると、内容やキャッシュ検証器が元ファイルと一致しません。
HTTPではbrとして交渉する
クライアントのAccept-Encodingにbrがあり、サーバーが選んだときContent-Encoding: brを返します。URLとMIMEタイプは同じでも、通信路上の表現データが変わります。
gzipしか受けないクライアントへbrを固定送信しません。キャッシュ鍵へAccept-Encodingを反映し、Content-LengthはBrotli圧縮後の本文長として扱います。
ストリーム自体にファイル名やチェックサムはない
RFC 7932のBrotli圧縮済みデータ形式は圧縮ストリームを定めますが、gzipのような元ファイル名、更新時刻、全体CRC32を包むファイルヘッダー・末尾情報ではありません。必要なら外側のコンテナーやプロトコルでメタデータと完全性を持たせます。
デコーダーエラーがないことは、期待した送信者から完全なデータを得た証明ではありません。HTTPS、署名、認証済みハッシュ等と役割を分けます。
展開上限と圧縮サイドチャネル
Brotliでも小さな入力が大きく展開されます。展開後大きさ、時間窓、メモリー、処理時間を制限します。HTTPヘッダーの宣言大きさだけを信用しません。
秘密情報と攻撃者入力を同じ圧縮文脈へ入れ、圧縮後大きさを観測できる構造では情報が漏れる可能性があります。圧縮形式を替えるだけでは解決せず、秘密情報との分離が必要です。
Brotliは後方参照、ハフマン符号化、文脈モデル化、組み込み辞書を使う可逆圧縮ストリームです。品質・時間窓・事前圧縮・HTTP交渉・外部の完全性保護を用途で設計します。
Brotli bitstream・dictionary・context・meta-block：RFC 7932／HTTP br content coding：RFC 9110