パケットの重みを知る者へ：HTTP/1.1圧縮機構の深層と、CPU・帯域のトレードオフ
ネットワークの現場に身を置く者なら誰しも、深夜の障害対応で`tcpdump`のキャプチャ画面を睨みつけ、MSSの切れ目やウィンドウサイズの一挙手一投足に神経を尖らせた経験があるはずだ。パケットの1オクテット、レイテンシの1ミリ秒を削り出すことに執念を燃やす我々にとって、HTTP/1.1の転送効率化は、単なるベストプラクティスではなく、インフラエンジニアとしての矜持そのものである。
今回は、HTTP/1.1が持つ基本にして極めて強力な武器、`Content-Encoding`と圧縮機構（gzip/deflate）を取り上げる。教科書に書いてあるような「帯域が節約できます」といった浅い話はここではしない。クライアントとサーバーのハンドシェイクの裏側で何が起きているのか、TCPバッファやTLSの暗号化レイヤーとどう交錯するのか、そして、実運用で踏み抜く地雷の数々を、パケットレベルの解像度で解き明かしていこう。
—
1. ネゴシエーションの裏側：Accept-Encoding と Content-Encoding の舞踏会
HTTP/1.1における圧縮は、クライアントとサーバーの静かなる合意形成から始まる。このプロセスは、単に「圧縮したデータを投げる」のではなく、厳密なメタデータのやり取りによって担保されている。
クライアント（ブラウザやAPIクライアント）は、リクエストヘッダーの `Accept-Encoding` で自分が解釈できる圧縮アルゴリズムのリストをサーバーに提示する。
GET /api/v1/telemetry HTTP/1.1
Host: api.example.com
Accept-Encoding: gzip, deflate, br
User-Agent: Mozilla/5.0 (X11; Linux x86_64) …
このリクエストを受け取ったリバースプロキシやオリジンサーバーのアプリケーションは、ハンドラーの処理結果（JSONやHTMLなど）をオンデマンド、あるいは事前に用意されたキャッシュから取り出し、対応するアルゴリズムでペイロードを圧縮する。そしてレスポンスヘッダーに `Content-Encoding` を付与して送り返す。
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
Transfer-Encoding: chunked
[compressed binary payload…]
ここでプロフェッショナルとして見落としてならないのが `Vary: Accept-Encoding` ヘッダーの存在だ。プロキシキャッシュ（CDNやVarnishなど）を運用している場合、このヘッダーを落とすことは「異なる `Accept-Encoding` を持つクライアント間で間違ったキャッシュ（未圧縮を求めているクライアントにgzip済みレスポンスを返すなど）を爆発させる」という重大なインシデントへの片道切符となる。キャッシュレイヤーの設計において、`Vary` の制御は生命線なのだ。
—
2. 内部挙動：gzip と deflate の正体と、CPU・帯域の永久なるトレードオフ
さて、ここでアルゴリズムの内部に目を向けてみよう。一般的に使われる `gzip` は、DEFLATEアルゴリズム（LZ77とハフマン符号化の組み合わせ）に加え、10バイトのヘッダーとCRC32チェックサム、そしてISIZE（非圧縮時のデータサイズ）のフッターが付加される形式だ。一方、HTTPの文脈における `deflate` は、RFC 1950に基づくZlibフォーマット（ヘッダーとAdler-32チェックサム）を指すことが多いが、実装によっては生データのDEFLATE（RFC 1951）を返すサーバーもあり、歴史的な経緯からブラウザ側の解釈に微妙な揺らぎが存在する。このため、現代のWebアーキテクチャでは事実上の標準である `gzip`（あるいはモダンな `br`（Brotli））を選択するのが最も堅牢である。
ここで発生するのが、インフラエンジニアを悩ませる永遠の課題、「CPU負荷とネットワーク帯域のトレードオフ」だ。
圧縮レベルを上げる（例：gzipのレベルをデフォルトの6から最大の9にする）と、CPUのサイクルは大きく消費される。LZ77のウィンドウサイズ内で一致するパターンを探索するアルゴリズムの計算量は、レベルを上げるにつれて非線形に跳ね上がるからだ。
- 帯域幅がボトルネックの環境（モバイル回線や遠隔リージョン間）：
CPUを多少叩いてでもパケットサイズを極限まで小さくし、TCPの慢性的輻輳回避（スロースタートやパケットロスからの回復）にかかる時間を短縮するべきである。
- CPUがボトルネックの環境（高スループットを要求されるAPIサーバー群、K8sの過密ポッド）：
過剰な圧縮はCPUのコンテキストスイッチやI/O待ちを誘発し、かえってレイテンシ（TTFB: Time To First Byte）を悪化させる。
このトレードオフを最適化するため、NginxなどのWebサーバーでは、動的圧縮（Dynamic Compression）の閾値を設定することが常道となる。
—
3. 実践：Nginxにおける高度な圧縮・バッファチューニング設定
現場で即座に使える、パフォーマンスを極限まで引き出すNginxの設定例を見てみよう。ここでは、CPU負荷を抑制しつつ、TCPの送信バッファ効率を最大化するパラメータを組み込んでいる。
http {
# 圧縮機能の有効化
gzip on;
# プロキシ経由のリクエストであっても確実に圧縮を適用する
# (CDNやロードバランサーの背後にあるオリジンサーバーで必須)
gzip_proxied expired no-cache no-store private auth;
# 圧縮対象とするMIMEタイプ
# 画像や動画などの既にエントロピーが高い(圧縮済みの)フォーマットは除外する
gzip_types
text/plain
text/css
text/javascript
application/javascript
application/json
application/xml
image/svg+xml;
# 極端に小さなレスポンスは、圧縮のオーバーヘッド(ヘッダー付加等)の方が
# 大きくなるため、最小サイズ(バイト)を設定
gzip_min_length 1024;
# CPU負荷と圧縮率のバランスを取るため、レベルは「5」あたりがスイートスポット
gzip_comp_level 5;
# HTTP/1.1のチャンク転送時に圧縮バッファを効率的に確保する
# バッファサイズを最適化することで、システムコール(write)の回数を削減する
gzip_buffers 16 8k;
# 古いHTTP/1.0クライアントを切り捨てる場合(基本はHTTP/1.1を前提とする)
gzip_http_version 1.1;
# Varyヘッダーを自動付与し、プロキシキャッシュの汚染を防ぐ
gzip_vary on;
}
この設定における `gzip_buffers 16 8k` の指定は、Linuxカーネルのネットワークスタックと深く関連している。カーネルのソケット送信バッファ（`SO_SNDBUF`）やTCPウィンドウサイズとの調和を図ることで、ユーザー空間からカーネル空間へのデータコピー効率が劇的に向上し、CPUキャッシュヒット率の改善に寄与するのだ。
—
4. プロトコルの交差点：TLSハンドシェイク、TCPバッファ、そしてセキュリティ
ここで視点をレイヤーの下層へとシフトさせよう。HTTP/1.1の圧縮を語る上で避けて通れないのが、トランスポート層およびセキュリティ層との密接な関係だ。
TLSとの罠：CRIME攻撃と情報漏洩
かつて、TLS上で圧縮されたHTTPトラフィックを狙う CRIME攻撃 や BREACH攻撃 という深刻な脆弱性が猛威を振るった。これは、暗号化されたHTTPSストリーム内において、平文のCookieやセッションIDと、攻撃者が任意のJavaScriptから送り込んだリクエストのデータが同じ圧縮コンテキスト（gzip）で処理される際、圧縮後の「バイト数の変化」を観測することで、秘密情報を総当たり的に復元できてしまうというものだった。
この教訓から、現代のモダンなTLS実装やブラウザ、HTTP/2、HTTP/3の世界では、TLS層での圧縮（TLS Compression）は完全に無効化されている。しかし、HTTPアプリケーション層での `Content-Encoding: gzip` は依然として生き残っており、動的なレスポンスに対する適切なスコープ管理（機密性の高いトークンやセッション情報を含むレスポンスに対する圧縮の除外など）がセキュリティ上、今なお極めて重要視されている。
RTT削減とTCPスロースタートの呪縛
HTTP/1.1は、原則として1つのTCPコネクション上でリクエストとレスポンスを直列に処理する（パイプライン化は実質的にブラウザ側で無効化されているか、制限がある）。そのため、ペイロードのサイズを小さく抑えることは、TCPの「初期輻輳ウィンドウ（InitCWND）」の制約をクリアする上で決定的な意味を持つ。
通常、LinuxカーネルのデフォルトではInitCWNDは10セグメント（約14.6KB）程度に設定されている。もし、未圧縮のAPIレスポンスが25KBであれば、最初のRTTで送信しきれず、ACKの返却を待つための2回目のRTT（追加の往復遅延）が発生する。しかし、`Content-Encoding` によってこれを11KBに圧縮できれば、最初の1回のRTT（Initial Round Trip）の枠内に収まり、体感レイテンシを劇的に削減できるのだ。
—
結び：パケットを愛する者たちのために
HTTP/1.1の `Content-Encoding` は、枯れた技術のように見えるかもしれない。しかし、その背後には、CPUのサイクル数、カーネルのメモリバッファ、TCPの輻輳制御アルゴリズム、そして暗号化のセキュリティ境界が複雑に絡み合う、インフラアーキテクチャの縮図が広がっている。
「なんとなく設定ファイルをコピペして動いた」で満足するステージは卒業しよう。自らが設計・運用するネットワークのパケットが、どのレイヤーでどのように圧縮され、クライアントの元へと駆け抜けていくのか。その全貌を脳内で完全にビジュアライズできた時、あなたのインフラストラクチャは、真に堅牢で最高速のパフォーマンスを発揮する要塞へと生まれ変わるはずだ。
コメント