帯域は「神」からの授かり物ではない：HTTP圧縮ネゴシエーションの深淵
ネットワークエンジニアとして現場を渡り歩いていると、往々にして「なぜページ表示が遅いのか？」という問いに直面する。インフラの帯域を太くするだけで解決する問題なら楽なのだが、現実はそう甘くない。光速の物理的制約と、TCPの輻輳制御アルゴリズムが支配する世界では、「いかに通信量を減らすか」が絶対正義となる。
今回は、HTTP/1.1の礎石であり、現代のHTTP/3（QUIC）に至るまで脈々と受け継がれる「HTTP圧縮ネゴシエーション」の真髄、`Accept-Encoding`と`Content-Encoding`の力学について、パケットレベルの解像度で紐解いていこう。
—
1. ネゴシエーションの真実：ハンドシェイクの裏側
ブラウザ（クライアント）がリクエストを投げる際、`Accept-Encoding: gzip, deflate, br` というヘッダーを乗せる。これは単なる文字列ではない。サーバーに対する「俺はこれらを解凍できるエンジンを積んでいる。お前のCPUリソースを使ってでも、俺に送るデータを圧縮してくれ」という、計算資源と帯域のトレードオフを定義する契約書だ。
パケットの視点：なぜ圧縮が必要か
TCP/IPの観点から見れば、データはセグメント（MSS: Maximum Segment Size）単位でパケットに切り刻まれる。100KBのレスポンスを圧縮して30KBにできれば、単に「通信が速くなる」だけではない。
1. TCPスロースタートの回避: 初期輻輳ウィンドウ（initcwnd）の制限下で、より多くの情報を初回のラウンドトリップに押し込める。
2. RTTの節約: コンテンツが小さいほど、TCPのACK待ちによる「往復」を減らせる。
3. バッファの最適化: サーバー側のソケットバッファに滞留する時間が短縮され、メモリ負荷が下がる。
—
2. 実装の妙：Content-Encodingの正しいハンドリング
サーバー側で `Content-Encoding` を付与する際、単に圧縮するだけでは不十分だ。特にセキュリティの観点から注意すべき点がある。
Nginxでのgzip設定例
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml;
gzip_min_length 1000; # 小さなファイルは圧縮のオーバーヘッドが勝るため対象外にする
gzip_proxied any; # キャッシュサーバーを経由しても圧縮を維持
gzip_vary on; # 重要：Vary: Accept-Encoding を付与してキャッシュの汚染を防ぐ
ここで最も重要なのが `Vary: Accept-Encoding` だ。これがないと、CDNやプロキシサーバーが「非圧縮版のレスポンス」をキャッシュし、それを「圧縮対応のブラウザ」に返してしまうという悲劇が起きる。あるいはその逆の「圧縮版」を「非対応ブラウザ」に返せば、ユーザーの画面にはブラウザが解釈不能なバイナリの羅列が並ぶことになる。
—
3. セキュリティの陥穽：CRIMEとBREACH攻撃
圧縮はパフォーマンスの味方だが、暗号化（TLS）との相性には注意が必要だ。
過去に猛威を振るった CRIME (Compression Ratio Info-leak Made Easy) や BREACH 攻撃を覚えているだろうか。これらは、TLS圧縮（現在は廃止）やHTTP圧縮の性質を悪用し、「圧縮後のサイズ」を観測することで、暗号化されたクッキーなどの秘密情報を推測する手法だ。
- 教訓: 秘密情報（CSRFトークンなど）が含まれるレスポンスに対しては、動的な圧縮を無効化するか、トークンのランダム化（Masking）を徹底すること。特にWebアプリケーションファイアウォール（WAF）レベルでの静的コンテンツと動的コンテンツの切り分けが重要になる。
—
4. アーキテクトへの提言：次のステージへ
現代のネットワークアーキテクチャでは、単なるgzipでは不十分だ。より圧縮率の高い `Brotli (br)` への移行を強く推奨する。Brotliはgzipと比較してテキスト圧縮率が15〜20%向上する。
さらに、トランスポート層での最適化として以下のカーネルパラメータチューニングを検討してほしい。
LinuxカーネルのTCPバッファチューニング
RTTが長い通信環境で、スループットを維持するためのバッファ拡大
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem=”4096 87380 16777216″
sysctl -w net.ipv4.tcp_wmem=”4096 65536 16777216″
これらの設定は、圧縮された高密度なパケットを、TCPパイプライン上で淀みなく流し続けるために不可欠なインフラの血管を太くする作業だ。
—
結論：パケットに愛を込めて
HTTPの圧縮ネゴシエーションは、単なるテキストの圧縮ではない。それは、クライアントのCPU、サーバーのI/O、そして我々が共有するネットワーク帯域という限られた資産を、いかにエレガントに最適化するかという「エンジニアリングの美学」そのものだ。
教科書的な知識で満足せず、パケットキャプチャをとり、Wiresharkのフローグラフを眺め、サーバーのCPU負荷とクライアントのレンダリング開始時間（FCP）の相関を計測してほしい。そこにこそ、真のネットワーク・アーキテクトが辿り着くべき回答がある。
さあ、次はどのプロトコルを解体しようか？
コメント