HTTP/1.1の「圧縮」を極める：パケットの断片から紐解く通信効率の極致
HTTP/1.1が登場して四半世紀以上が経過したが、今なおWebのトラフィックの大部分を支えるこのプロトコルには、エンジニアの腕が試される「圧縮」という名の深淵が広がっている。
多くのエンジニアは `Content-Encoding: gzip` を単なるおまじないとして設定し、ChromeのDevToolsで「お、サイズが減ったな」と満足して終わりにする。だが、インフラアーキテクトとしてパケットレベルまで視座を下げたとき、そこにはTCPのウィンドウ制御やCPUサイクル、そしてセキュリティという、幾重にも重なる最適化の戦場が見えてくるはずだ。
コンテントネゴシエーションの真実：Accept-Encodingの裏側
ブラウザから送信される `Accept-Encoding: gzip, deflate, br` というヘッダーは、単なる希望ではない。これはサーバーに対する「ここまで展開（解凍）できる計算リソースが手元にある」という宣言だ。
ここで注意すべきは、`deflate` の実装の曖昧さだ。RFC 2616（HTTP/1.1）におけるdeflateは、実はZlibの仕様と混同されやすく、古いクライアントやサーバーの間で「raw deflateか、zlibラッパー付きか」という不毛な解釈の不一致が長年トラブルの種となってきた。今、我々が選択すべきは、圧縮率と計算効率のバランスが優れた `br` (Brotli) か、枯れた信頼性を持つ `gzip` である。
圧縮がもたらす「トランスポート層」への副作用
圧縮を有効にするということは、アプリケーション層でデータを小さくするだけではない。TCPスタックの振る舞いに直接的な影響を与える。
RTT削減とTCPウィンドウのパズル
データが圧縮されれば、単一のTCPセグメントに収まる情報密度が高まる。これは、Slow Startフェーズにおいて、少ない往復時間（RTT）でより多くの情報をアプリケーションへ届けることを意味する。
しかし、ここで忘れてはならないのがTCPバッファチューニングだ。圧縮されたレスポンスは、往々にして急激なデータバーストを生む。サーバー側の `net.ipv4.tcp_wmem` を適切に設定しておかなければ、圧縮したデータを送り出した瞬間にソケットバッファが溢れ、パケットロスによる再送という「圧縮によるパフォーマンス向上の恩恵を全て打ち消す最悪の事態」を招くことになる。
TCPウィンドウサイズの最適化例（Linuxカーネルパラメータ）
圧縮によるデータ転送の急増を捌くためのバッファ拡大
sysctl -w net.ipv4.tcp_wmem=”4096 65536 16777216″
sysctl -w net.ipv4.tcp_rmem=”4096 87380 16777216″
暗号化との共存：TLSハンドシェイクとBREACH/CRIME攻撃
セキュリティの観点から避けて通れないのが、TLSと圧縮の間の緊張関係だ。
かつて、TLSレベルでの圧縮がCRIME攻撃によって悪用されたのは記憶に新しい。現代のインフラでは「TLSレベルの圧縮」は無効化するのが鉄則だが、HTTPレベルの `Content-Encoding` もまた、SSL/TLSで暗号化されたストリーム上で動作するため、BREACH攻撃という脅威に晒される可能性がある。
攻撃者は、圧縮後のサイズの変化を観測することで、暗号化されたCookie内の秘密トークンを推測する。これを防ぐためには、以下の対策が必須だ。
1. CSRFトークンの分離: レスポンスボディにトークンを埋め込む際は、可変のコンテンツと分離する。
2. TLSのオーバーヘッドを考慮したパディング: 圧縮後のサイズが予測可能なパターンにならないよう、微小なランダムノイズを付加する（ただし、これは実装コストが極めて高い）。
3. HTTP圧縮の対象を限定する: 動的生成されるHTML（トークンが含まれる可能性が高い）への圧縮には細心の注意を払う。
実践的チューニング：nginxで制御する圧縮の境界
最後に、現場で即座に活かせるnginxの設定例を提示する。闇雲に全てを圧縮するのは、CPU負荷を高めるだけで逆効果だ。
nginx.conf の一例
gzip on;
小さなファイル（1KB未満）を圧縮しても、ヘッダーのオーバーヘッドで逆に肥大化する
gzip_min_length 1024;
圧縮レベルは「4〜6」がCPU負荷と圧縮率のスイートスポット
gzip_comp_level 5;
圧縮対象のMIMEタイプを厳選する
gzip_types text/plain text/css application/json application/javascript text/xml;
プロキシ経由でも圧縮を有効にする（バックエンドが圧縮済みでも再圧縮しない）
gzip_proxied any;
なぜ「gzip_comp_level 9」を設定してはいけないのか
多くのジュニアエンジニアは圧縮レベルを最大にしたがる。しかし、CPUのコストは指数関数的に増大するのに対し、圧縮率の向上は頭打ちになる。ネットワーク帯域がボトルネックなのか、CPUがボトルネックなのかを `htop` や `iostat` で監視し、自身のインフラに適した値を見極めるのが、真のアーキテクトの仕事だ。
結びに代えて：パケットに心を通わせる
HTTP/1.1という枯れた技術であっても、圧縮という一点を深掘りするだけで、TCPのウィンドウ制御からセキュリティの脆弱性まで、インフラの全レイヤーを横断する深い洞察が求められる。
技術とは、単に仕様通りに動かすことではない。プロトコルが持つ特性を理解し、その裏でパケットがどのような緊張感を持ってネットワークを駆け巡っているのかを想像し続けることだ。圧縮は、その想像力を試す最も身近で、かつ奥深い最適化の入口なのである。
コメント