【入門編】HTTP/1.1のContent-Encodingヘッダーと圧縮アルゴリズム – HTTPプロトコル・通信規格実践ガイド

ネットの「重い荷物」を小さく畳む魔法：HTTP/1.1の圧縮技術をマスターしよう

こんにちは！ネットワークの世界へようこそ。
Webサイトを見ているとき、「読み込みが遅いな」と感じたことはありませんか？実は、その裏側では、サーバーからあなたのブラウザへ、膨大なデータという名の「荷物」が絶え間なく届けられています。

この荷物が大きすぎると、配達（通信）に時間がかかってしまいますよね。そこで登場するのが、HTTP/1.1の圧縮技術です。今日は、この「荷物を小さく畳んで送る」という賢い仕組みについて、一緒に紐解いていきましょう。

—

想像してみてください。あなたは、分厚い辞書を友人に送ろうとしています。そのまま送れば送料もかさむし、配達員さんも大変ですよね。でも、もし辞書の内容を「要約」して小さなメモに書き写し、それを封筒に入れて送ったらどうでしょう？

友人（ブラウザ）は、そのメモを受け取ったあと、元の辞書の内容を復元（解凍）して読み取ります。

HTTPの圧縮も、まさにこれと同じです。

このやり取りのおかげで、私たちはWebサイトをサクサクと快適に閲覧できているんです。

—

ここで一つの疑問が浮かびます。「サーバーは、ブラウザが解凍できる形式を知っているの？」ということ。

ここで使われるのが、「Accept-Encoding（受け入れ可能な圧縮形式）」というヘッダーです。ブラウザはサーバーに「私はgzipなら解凍できるよ！」と事前に伝えます。

これを「コンテント・ネゴシエーション（内容の交渉）」と呼びます。

GET /index.html HTTP/1.1
Host: example.com
「gzipっていう圧縮形式なら解凍できるよ！」と伝えています
Accept-Encoding: gzip, deflate

HTTP/1.1 200 OK
「了解！じゃあgzipで圧縮して送るね」という合図
Content-Encoding: gzip
Content-Type: text/html

(ここに圧縮されたバイナリデータが続きます…)

サーバーが「よし、gzipで送るよ！」と決めると、`Content-Encoding`というヘッダーにその名前を書いて、圧縮されたデータを返してあげるのです。

—

現場でよく耳にする「gzip」や「deflate」は、データの畳み方（アルゴリズム）の種類の名前です。

最近では、より性能の良い「Brotli（ブロットリ）」という形式も普及していますが、HTTP/1.1の基本を学ぶ上では、まずはgzipの挙動をしっかり押さえておけば間違いありません！

—

みなさんが普段使っているブラウザの「開発者ツール（F12キー）」を開いてみてください。「ネットワーク」タブを見てみると、実際にどんなデータがやり取りされているかが見えます。

特定のファイルを選択して「レスポンスヘッダー」を確認すると、そこに `Content-Encoding: gzip` という記述が見つかるはずです。これが見えたら、「お、このデータは圧縮されて届いているんだな！」と理解できている証拠です。

もし皆さんが将来サーバーを構築するなら、設定ファイルにはこんな風に書きます。

圧縮を有効にする設定
gzip on;

圧縮するデータの種類（HTMLやCSSなどはテキストなので圧縮効果が高い！）
gzip_types text/plain text/css application/json application/javascript;

圧縮のレベル（1〜9で指定。数字が大きいほど小さくなるが、CPU負荷も上がる）
gzip_comp_level 6;

—

今回学んだのは、ネットワークにおける「効率化」の基礎の基礎です。

1. ブラウザが「これなら解凍できるよ！」と伝える。
2. サーバーが「じゃあそれで圧縮して送るね」と応じる。
3. データが小さくなって、爆速で届く。

この単純かつ美しいやり取りが、世界中のWebサイトを支えています。最初は「ヘッダー？アルゴリズム？」と難しく感じるかもしれませんが、こうして「郵便配達」に例えれば、ぐっと身近に感じられるはずです。

これからも一歩ずつ、技術の面白さを一緒に探求していきましょうね。次回は、この通信をもっと高速化する「キャッシュ」の仕組みについてお話しする予定です。お楽しみに！