【入門編】HTTP/1.1のContent-Encodingと圧縮（gzip, deflate） – HTTPプロトコル・通信規格実践ガイド

こんにちは！ネットワークの世界へようこそ。今日は、Webサイトが皆さんのスマホやPCに表示されるまでの「裏側」にある、ちょっと賢い工夫についてお話しします。

普段、Webサイトを見ていると、画像や文字が瞬時にパッと表示されますよね。実はこれ、ただ通信速度が速いだけではないんです。ネットワークのエンジニアたちは、「限られた時間で、いかに効率よくたくさんの荷物を運ぶか」というパズルを常に解いています。

今日は、そのパズルを解くための強力な武器、「圧縮転送（Content-Encoding）」という仕組みを紐解いていきましょう。

—

例えば、皆さんが海外の友人に、ものすごく分厚い辞書を郵便で送ると想像してみてください。そのまま送ると送料も高いですし、到着まで時間もかかりますよね？

もし、その辞書を「専用の圧縮機」でペチャンコにして、封筒に入るサイズまで小さくできたらどうでしょう？
1. 送料（通信コスト）が安くなる
2. 届くのが早くなる（転送速度の向上）

Webの世界でも同じです。Webサーバー（郵便局）は、ブラウザ（受け取り人）へデータを送る前に、データをギュッと圧縮して送り出しています。これが「Content-Encoding」の正体です。

—

ここで一つ問題があります。もし郵便局が、受け取り人が「解凍機（圧縮を元に戻す道具）」を持っていないのに、圧縮された荷物を送ったらどうなるでしょうか？受け取り人は中身が見られず、困ってしまいますよね。

そこで、HTTP/1.1では非常にスマートなルールが用意されています。

1. 「私、圧縮機持ってるよ！」（ブラウザ）
ブラウザがサーバーに「この荷物をお願いします！」と頼むとき、`Accept-Encoding`という合言葉を添えます。
「私は『gzip』という圧縮形式なら解凍できるよ！」と伝えるわけです。

2. 「じゃあ圧縮して送るね！」（サーバー）
サーバーはその合言葉を見て、「よし、じゃあgzip形式で小さくして送るよ！」と判断し、圧縮したデータを送信します。

このやり取りのおかげで、お互いに「話が通じない」という事故を防いでいるんですね。

—

皆さんがWebサーバーを構築する際、よく使われる「Apache」や「Nginx」というソフトでは、この圧縮設定を以下のように記述します。

圧縮を有効にする
gzip on;

どんな種類のファイルを圧縮するか（テキスト系は効果大！）
gzip_types text/plain text/css application/json application/javascript;

圧縮レベル（1〜9で指定。数字が大きいほど小さくなるが、CPUを消費する）
gzip_comp_level 6;

—

ここで、インフラエンジニアとして覚えておいてほしい大切な教訓があります。それは、「圧縮にはコストがかかる」ということです。

圧縮のメリット： 通信量が減るため、ネットワークの渋滞が解消され、ユーザーへの到着が早くなる。
圧縮のデメリット： サーバー側で「圧縮する作業」、ブラウザ側で「解凍する作業」が発生するため、CPU（サーバーやスマホの脳みそ）に負荷がかかる。

「じゃあ、限界まで圧縮しよう！」と設定レベルを最大（9など）にすると、通信はわずかに速くなるかもしれませんが、サーバーが一生懸命計算するせいで、逆にWebサイトの表示がもたついてしまう……なんてことも起こり得ます。

「ネットワーク帯域を節約するか、CPUパワーを節約するか」

このバランスを考えるのが、アーキテクトの腕の見せ所です。基本的にはレベル「4〜6」あたりが、速度とCPU負荷のスイートスポットと言われています。

—

HTTP/1.1の圧縮転送は、現代のWebを支える「縁の下の力持ち」です。

これらが連携することで、私たちは快適なネットサーフィンを楽しめています。次にWebサイトを見るときは、「今、この通信はどこかでギュッと圧縮されているのかな？」と想像してみてください。きっと、目に見えないパケットの旅が、今までよりも少しだけ身近に感じられるはずですよ。

それでは、また次回の技術探訪でお会いしましょう！