こんにちは！ネットワークとプロトコルの深淵を愛するインフラアーキテクトです。
日頃からWeb APIの設計や、フロントエンドとバックエンドの通信速度のチューニングに頭を悩ませているエンジニアの皆さん、お疲れ様です。「APIのレスポンスなんだか遅いな……」「JSONのデータ量をもっと小さくできないかな？」と感じたことはありませんか？
今回は、Webの通信においてなくてはならない「HTTP圧縮アルゴリズム（Gzip、Deflate、Brotli）」の世界へ皆さんをご案内します。
「パケットがどうこう」「複雑なアルゴリズムの数学的背景が……」といった難解なお話はひとまず置いておきます。まずは私たちの身近にある「荷物の宅配サービス」に例えながら、通信の裏側で何が起きているのか、一歩ずつ優しく紐解いていきましょう！
—
1. なぜWebの通信は「圧縮」が必要なの？（郵便配達のたとえ）
皆さんがオンラインショップで買い物をして、大きなダンボール箱が届いたときのことを想像してみてください。
もし、中身の洋服がふわっと広げられた状態で、わざわざ大きなトラックで1枚ずつ運ばれてきたらどうでしょう？「もっと小さく畳んで、コンパクトな封筒に入れて送ってよ！」って思いますよね。
インターネットの世界もこれとまったく同じです。
Webブラウザ（あなた）がサーバー（お店）に「このデータをちょうだい！」とリクエストを送ると、サーバーはデータベースから引っ張り出した大量のテキストデータ（JSONやHTMLなど）を返してくれます。
このとき、データをそのままの大きさ（生データ）で送ると、次のような問題が起きるのです。
- ネットワーク回線の渋滞: 道路（回線）が太くても、荷物（データ）が大きすぎると、配達に時間がかかってしまいます。
- 表示スピードの低下: ユーザーが画面を開くまでの「待ち時間（レイテンシ）」が長くなり、サービスの離脱につながります。
そこで登場するのが、「HTTP圧縮」という技術です。サーバー側でデータをキュッと小さく「圧縮」して送り、受け取ったブラウザ側で「元の大きさに戻す（解凍する）」ことで、限られたネットワークの帯域を賢く節約しているんですね。
—
2. 主な3つの圧縮アルゴリズム（Gzip, Deflate, Brotli）の特性を知ろう
一言で「圧縮」と言っても、いくつか種類があります。現在、Webの世界で主に使われている代表的な3つのアルゴリズムを見ていきましょう。
Gzip（ジージップ）の安心感
- 特徴: Webの歴史において最も古くから使われている、いわば「定番の段ボール箱」です。
- メリット: ほぼすべてのブラウザやサーバーが標準で対応しており、迷ったらこれを選べば間違いありません。CPUの負荷も比較的軽めです。
Deflate（ディフレイト）の立ち位置
- 特徴: Gzipの基本技術と同じ仕組みを使った圧縮方式です。
- 注意点: 歴史的な経緯や仕様の解釈の違いから、実際のWebの現場ではGzipが選ばれることが多く、現在ではあまり主役になることはありません。
Brotli（ブロットリ）の圧倒的な実力者
- 特徴: Googleが開発した、比較的新しい「次世代の圧縮アルゴリズム」です。
- メリット: Gzipよりもさらに高い圧縮率（ファイルをより小さくできる）を誇ります。
- デメリット（トレードオフ）: 圧縮するのに「高いCPUパワー（計算量）」を必要とします。つまり、サーバーの息が少し上がってしまうことがあるのです。
—
3. 圧縮の裏側にある「CPU負荷と転送速度のトレードオフ」
ここで、インフラエンジニアとして避けて通れない重要なジレンマ（トレードオフ）についてお話しします。
圧縮技術の本質は、「サーバーのCPUにがんばってもらって（圧縮・解凍）、ネットワークの旅をラクにする（転送量削減）」というトレードオフのバランス取りです。
- Brotliを使う場合:
ファイルを極限まで小さくできるため、スマホなどのモバイル回線（速度が限られている環境）では抜群の速さを発揮します。しかし、サーバー側で圧縮処理を行う際にCPUをたくさん消費するため、アクセスの多い巨大なWebサイトではサーバーのCPUスペックに余裕を持たせる必要があります。
- Gzipを使う場合:
Brotliほどファイルは小さくなりませんが、CPUの消費が少なく、どんな古いサーバーでも軽快に動作します。
「じゃあ、常に一番圧縮率が高いBrotliにしておけばいいのでは？」と思いがちですが、サーバーのCPUが悲鳴を上げたり、オンザフライ（動的）な圧縮でレイテンシが悪化したりする場合もあるため、システムの特性に応じた選択が求められます。
—
4. 実際のブラウザとサーバーのやり取り（Content-Encodingの仕組み）
ブラウザとサーバーがどのように会話して圧縮方法を決めているのか、その流れを覗いてみましょう。
1. リクエスト（ブラウザからの要望）
ブラウザがサーバーにデータを要求するとき、「私、こういう圧縮形式なら読めるよ！」とこっそり伝えます。これが Accept-Encoding というヘッダーです。
Accept-Encoding: gzip, deflate, br （※ ここで br は Brotli のことです）
2. レスポンス（サーバーからの返答）
サーバーは、ブラウザが対応している形式の中から、自分が得意なもの（または設定されたもの）を選んでデータを圧縮し、こう返します。
Content-Encoding: br
Content-Type: application/json; charset=utf-8 この Content-Encoding: br というヘッダー受けることで、ブラウザは「おっ、Brotliで圧縮されているな。解凍して中身を読もう！」と判断するわけです。
—
5. 実務で役立つ設定サンプル（Nginx編）
それでは、実際のインフラ構築やWebサーバーの設定でどのように反映させるのか、代表的なWebサーバーである Nginx の設定例を見ていきましょう。
実務でそのままコピー＆ペーストして微調整できるよう、日本語の丁寧なコメントを添えています。
# HTTP圧縮（GzipおよびBrotli）の全体設定
http {
# --- Gzip圧縮の設定 ---
gzip on;
gzip_vary on;
gzip_min_length 1024; # 1KB未満の小さなファイルは、圧縮するオーバーヘッドの方が大きいため対象外にする
gzip_proxied any;
gzip_comp_level 6; # 圧縮レベル（1〜9）。高すぎるとCPUを食いすぎるため、バランスの良い「6」が定番
# 圧縮対象とするMIMEタイプ（テキストやJSON、JavaScript、CSSなど）
gzip_types
text/plain
text/css
text/xml
text/javascript
application/json
application/javascript
application/xml+rss;
# --- Brotli圧縮の設定（※モジュールが導入されている場合） ---
# Brotliは次世代の強力な圧縮方式ですが、サーバーのCPU負荷とのトレードオフを意識します
brotli on;
brotli_comp_level 6; # Brotliの圧縮レベル（0〜11）。一般的に4〜6あたりがCPUと圧縮率のスイートスポットです
brotli_types
text/plain
text/css
text/xml
text/javascript
application/json
application/javascript
application/xml+rss;
}設定のポイント
gzip_min_length 1024;: すべてのファイルを圧縮すればいいというわけではありません。数バイトのテキストを圧縮してもファイルサイズはほとんど変わらないどころか、圧縮・解凍の処理時間のほうが無駄になってしまいます。そのため、一定のサイズ（一般的には1KB〜）を超えるものだけを対象にします。- 圧縮レベル: Gzipなら
6、Brotliなら4〜6あたりが、CPU負荷とファイルサイズの縮小効果のバランスが最も優れている「黄金比」と言われています。
—
まとめ：モダンなWeb API設計に向けて
今回は、HTTP圧縮アルゴリズムの仕組みと、私たちが普段何気なく使っている裏側のトレードオフについて解説しました。
- Gzip: 迷ったらこれ。高い互換性と安定したパフォーマンス。
- Brotli: 転送量を極限まで減らせる次世代の選択肢。ただしサーバーのCPU負荷に注意。
- 仕組み: ブラウザの
Accept-EncodingとサーバーのContent-Encodingの合意によって成り立っている。
インフラやネットワークの世界は、一見すると難しそうに見えますが、身近なモノの例えに置き換えてみると、技術者たちがどのような意図でその仕組みを選んでいるのかがクリアに見えてきますよね。
皆さんが構築するAPIやWebサイトが、ユーザーのデバイスへ最速でデータを届けられるよう、今回の知識が少しでもお役に立てれば幸いです。それでは、次回の深淵でお会いしましょう！
コメント