はじめに
- ネットワークトラフィックを削減し、Web上で高速にテキストやバイナリ等のコンテンツをやり取りすることを目的に圧縮される
- 一般的に、ApacheやnginxのようなWebサーバ側で圧縮され、Webブラウザ側で解凍される
- 圧縮アルゴリズムには複数種類あるため、それぞれのメリットやデメリットについて整理してみる
HTTPヘッダ
- HTTPリクエスト/レスポンス上でどのように圧縮アルゴリズムの交渉がなされるのかという例示
HTTPリクエストヘッダ
- クライアントがどの圧縮アルゴリズムを解釈できるかを指定する
# 圧縮アルゴリズムを１つ指定するパターン
Accept-Encoding: gzip
# 圧縮アルゴリズムを複数指定するパターン
# 優先順位の高い順で指定する
Accept-Encoding: gzip, compress, br
# 圧縮アルゴリズムを複数指定するパターン
# それぞれを品質値と呼ばれ、`;q=`の形式で記述する方式で重み付けをしている
Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1
HTTPレスポンスヘッダ
- どの圧縮アルゴリズムによって圧縮されたかを指定する
Content-Encoding: gzip
# 複数適用されたパターン
# 適用された順に記述される
Content-Encoding: gzip, identity
圧縮アルゴリズム
- 圧縮アルゴリズムの評価軸としては、圧縮/解凍処理の高速性や圧縮率の高さ等がある
- 圧縮/解凍処理の遅さが圧縮率の低さによるボトルネックを上回らないようにすることが大切
- HTTPで一般的に使用できる圧縮アルゴリズムには以下のような種類がある
gzip
- GNU zipの略称でGNUプロジェクトでメンテされているzip形式の圧縮アルゴリズム
- Lempel-Ziv(LZ77)とハフマン符号を用いた圧縮アルゴリズム
- RFC 1952として標準化されている
- compressで使用されている圧縮アルゴリズムが特許侵害の問題を抱えていたことから開発が開始された
- compressよりも圧縮率が高いという特徴を持つ
compress
- Lempel-Ziv-Welch(LZW)を用いた圧縮アルゴリズム
- 特許侵害の問題を抱えていることや、他に優秀な圧縮アルゴリズムが台頭してきたことからあまり使用されなくなっている
deflate
- LZ77の改良版であるLempel–Ziv–Storer–Szymanski(LZSS)とハフマン符号を用いた圧縮アルゴリズム
- HTTP上で使用されるDeflateにはzlibヘッダが付与されている
- 一部のプログラムではzlibヘッダが付与されていない生のdeflateとして扱われる問題があるため、多少圧縮率が落ちてもgzipが採用される傾向にある
sdch
- SDCH(Shared Dictionary Compression for HTTP)
- VCDIFF(RFC 3284)をベースにGoogleが開発した
- Google Chromeのバージョン59でサポートが打ち切られ、後述のbrへの移行が進んでいる
br
- Brotilの略称
- 元々はWebフォントのオフライン圧縮を目的に開発されたものをGoogleが改良した
- Deflateと圧縮/解凍速度がほぼ同等のまま、20%の圧縮率の高さを実現できるとされている
identity
- 圧縮されていないことを表す
- この値は省略されていても常に許容されるものとして扱われる
*
- 指定可能な全ての圧縮アルゴリズムを表す
- これはクライアントが指定可能な全ての圧縮アルゴリズムを解釈できるという意味ではない
-
Accept-Encodingヘッダが設定されていない場合の既定値