GZIP完全解説:仕組み・歴史・Web圧縮の最適化とBrotli比較
GZIPとは
GZIP(ジーザーイプ、一般には「ギップ」と読まれることもあります)は、ファイル圧縮のためのプログラムとファイルフォーマットの名称です。もともとはGNUプロジェクトの「gzip(GNU zip)」として1992年にJean-loup GaillyとMark Adlerによって作られました。GZIPフォーマット自体はRFC 1952として定義され、圧縮アルゴリズムにはDEFLATE(LZ77 とハフマン符号の組合せ、RFC 1951)が使われます。
歴史と位置づけ
UNIX系で広く使われたcompress(LZW)に代わるツールとして登場し、高い圧縮率と速度のバランス、自由なライセンス(GNU)により急速に普及しました。WebではHTTPのContent-Encodingヘッダを通じて転送時の圧縮に使われ、ブラウザ側も長年サポートしてきました。近年はBrotliのような新しいアルゴリズムも登場していますが、互換性・ツール群の豊富さからGZIPは依然として広く利用されています。
仕組み(概要)
- アルゴリズム:GZIP自体はファイルフォーマット/ユーティリティで、実際の圧縮にはDEFLATEアルゴリズムを使います。DEFLATEはLZ77によるマッチ置換とハフマン符号化を組み合わせた可逆(ロスレス)圧縮方式です。
- ファイル構造:GZIPファイルはヘッダ(識別子0x1f 0x8b、圧縮方式=8(DEFLATE)など)・圧縮データ・トレーラ(CRC32と元の入力バイト数の下位32ビット=ISIZE)で構成されます。ヘッダには元ファイル名やタイムスタンプ・コメントなどのオプションフィールドを含めることができます(RFC 1952)。
- 単一ストリーム:.gzファイルは一つの圧縮ストリームを保持します。複数ファイルを一つにまとめたい場合は普通 tar によるアーカイブ(.tar)を先に作り、その後 gzip で圧縮して .tar.gz(または .tgz)にします。
GZIPと他のフォーマット(zlib、DEFLATE、ZIP との違い)
混同されやすいポイント:
- DEFLATE:圧縮アルゴリズムそのもの(RFC 1951)。
- zlib:DEFLATEデータにわずかなヘッダとチェックサム(RFC 1950)を付けたもの。ライブラリやAPIでよく使われるフォーマット。
- gzip:DEFLATEを用いるファイルフォーマット(RFC 1952)。zlibとヘッダ・トレーラの仕様が異なるため、互換性はない(ただし中身の圧縮アルゴリズムは同じ)。
- ZIP:複数ファイルを格納できるアーカイブ形式で、内部で様々な圧縮方法を使えます。.zip はGZIPとは別物です。
Web(HTTP)での利用
Webサーバはレスポンス圧縮のためにGZIPを利用できます。クライアントはAccept-Encoding ヘッダでサポートする圧縮方式(例: gzip, deflate, br)を示し、サーバは Content-Encoding: gzip を返して圧縮済みボディを送ります。多くのブラウザ・HTTPクライアントがgzip圧縮をサポートしています。
メリット:転送バイト削減、ページロード時間短縮、帯域節約。特にテキスト系(HTML, CSS, JavaScript, JSON, XML, SVG など)で効果が高いです。逆に画像(JPEG/PNG/WebP)や動画、すでに圧縮されたアーカイブは圧縮効果が小さいか無意味で、無駄なCPU負荷になります。
サーバ側設定例(代表的な設定)
設定例の一例を示します(実際の構成では環境に合わせて調整してください)。
- Nginx(代表的なディレクティブ):
- gzip on;
- gzip_vary on;
- gzip_proxied any;
- gzip_comp_level 6;
- gzip_types text/plain text/css application/javascript application/json application/xml text/xml image/svg+xml;
- gzip_min_length 256;
- Apache(mod_deflate):
- AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/javascript application/json image/svg+xml
コマンドラインと運用(よく使うオプション)
- gzip file (元ファイルを圧縮し file.gz を作る)
- gzip -d file.gz または gunzip file.gz(解凍)
- gzip -k file(元ファイルを残して圧縮)
- gzip -9 file(最高圧縮。遅いが圧縮率優先) / gzip -1(高速だが圧縮率は低い)
- gzip -l file.gz(圧縮前後のサイズの一覧表示)
- zcat file.gz(解凍して標準出力へ)
- tar czf archive.tar.gz dir/(tar と組み合わせてディレクトリを圧縮) / tar -xzf archive.tar.gz(展開)
- pigz:マルチコアを利用する並列gzip実装(大きなファイル圧縮で高速化)
パフォーマンスとベストプラクティス
- 圧縮レベルの選定:サーバCPUと帯域のバランスで選ぶ。一般的に6前後が妥当なトレードオフ。
- 事前圧縮(pre-compress):静的アセットはデプロイ時に .gz を作成しておき、サーバはクライアントのAccept-Encodingを見て事前圧縮ファイルを返す。オンザフライ圧縮よりレスポンス遅延が小さい。
- 最小長設定:小さなレスポンスはHTTPヘッダとのオーバーヘッドにより圧縮の効果がないため、gzip_min_lengthのような閾値を設ける。
- キャッシュとVaryヘッダ:gzip有効時は Vary: Accept-Encoding を返すことでプロキシ/キャッシュが異なるエンコーディングを区別するようにする。
- 圧縮対象のMIMEタイプを限定:画像や動画など既に圧縮済みのMIMEタイプは除外する。
セキュリティと注意点
- 暗号化ではない:GZIPは圧縮手段であり暗号化ではありません。機密データを隠す手段として使ってはいけません。
- 圧縮に起因する攻撃:CRIMEやBREACHのように、圧縮+暗号化(HTTPS)やレスポンス中の機密情報の存在を利用して情報漏洩を誘発する攻撃があります。特にレスポンス内に攻撃者が予測可能な入力と機密データが同じ圧縮ストリームに含まれる場合にリスクがあります。必要に応じてTLSレベルの圧縮を無効にしたり、レスポンス設計を見直すことが推奨されます(OWASP等のガイドライン参照)。
- リソース消費:大量の解凍処理や特別に作られた「圧縮爆弾(zip bomb)」のようなファイルによりディスクやメモリ、CPUを枯渇させられるリスクがあります。外部入力の検査やリソース制限(タイムアウト、メモリ制限)を行うことが重要です。
- ヘッダの正しい扱い:VaryやContent-Encodingの扱いを誤るとキャッシュ汚染や想定外のデータ返却を招く可能性があります。
近年の潮流:Brotli との比較
Brotli はGoogleが開発し、Web向けに最適化された可逆圧縮アルゴリズムで、特にHTTPコンテンツ圧縮でGZIPより高い圧縮率を示すことが多いです(特にテキスト系)。現代のブラウザとCDNはBrotliをサポートしているため、新規にWeb圧縮を設定する際はBrotliを優先し、クライアント非対応時にGZIPをフォールバックするといった構成が推奨されます。ただし、Brotliの圧縮コストや対応状況は環境により異なるため、検証が必要です。
まとめ
GZIPは長年にわたり広く使われてきた信頼性の高い圧縮ツールとフォーマットです。Webでは転送量削減とレスポンス高速化のための標準的手段として定着しており、ツールやサーバ設定のサポートも豊富です。一方で、圧縮レベルの選定、対象MIMEの適切な設定、セキュリティリスク(圧縮に起因する攻撃)といった運用面の注意が必要です。最近はBrotliなどの新しいアルゴリズムも台頭しているため、用途に応じて最適な方式を選択・検証することが重要です。
参考文献
- RFC 1952 - GZIP file format specification version 4.3
- RFC 1951 - DEFLATE Compressed Data Format Specification
- RFC 1950 - ZLIB Compressed Data Format Specification
- GNU gzip (公式サイト)
- MDN: Content-Encoding
- Nginx: ngx_http_gzip_module
- Apache: mod_deflate
- MDN: Brotli(ブラウリ)概要
- OWASP: BREACH 攻撃概要
- OWASP: CRIME 攻撃概要
- pigz — parallel implementation of gzip
- Zip bomb(圧縮爆弾) — Wikipedia


