HTTP/1.1の呪縛を解き放て：SPDYが変えた「通信の流儀」とパケットの深層
ネットワークの世界に身を置く者であれば、誰もが一度はHTTP/1.1の「限界」に絶望したことがあるはずだ。テキストベースのプロトコル、ヘッド・オブ・ライン・ブロッキング（HOLB）、そしてRTTを食い潰す無駄なハンドシェイク。SPDY（スピーディ）がGoogleの研究所から世に出たとき、それは単なる技術アップデートではなく、Webのインフラを根本から再定義する宣戦布告だった。
今回は、HTTP/1.1の泥沼から我々を救い出した「ストリーム」と「バイナリフレーム」の概念を、単なる仕様の解説ではなく、パケットがワイヤー上を駆け巡る「物理的な現実」の視点から紐解いていく。
—
1. テキストベースの虚妄とバイナリフレームの真実
HTTP/1.1は人間が読むには適していたが、マシンが処理するにはあまりに非効率だった。`GET /index.html HTTP/1.1\r\n` といった文字列をパースし、ヘッダーの終端をCRLFで探す……このCPUサイクルは、高負荷なサーバーでは馬鹿にならないオーバーヘッドとなる。
SPDYが導入した「バイナリフレーム」は、この非効率を根底から覆した。
- Fixed Header: すべてのフレームが固定長のヘッダーを持つため、境界値の判定が極めて高速。
- バイナリ化: 数値やフラグを直接ビットとして表現することで、パース負荷を最小化。
これにより、パケットを解析するNIC（ネットワークインターフェースカード）に近いレイヤーでの処理コストが劇的に低下した。例えば、以下の構造を見ればその差は歴然だ。
/ SPDYフレームの概念的な構造（擬似コード） /
struct spdy_frame {
uint16_t type : 15; // フレームタイプ（DATA, SYN_STREAM, HEADERS等）
uint16_t control : 1; // 制御ビット
uint32_t stream_id : 31; // どのストリームに属するパケットか
uint8_t flags : 8; // 圧縮フラグやFINフラグなど
uint32_t length : 24; // ペイロード長（パースを容易にする）
unsigned char data[]; // ここに圧縮されたヘッダーやデータが続く
};
この構造により、CPUは「次に何が来るか」を事前に予測し、バッファを最適に確保できるようになった。これは単なる効率化ではなく、「パケットを読み解く文法」の刷新なのだ。
—
2. ストリーム多重化：HOLBとの決別
HTTP/1.1における最大の問題は、TCP接続一つにつき一つのリクエストという「直列処理」にあった。画像一つが詰まれば、あとのリソースはすべて待機させられる。SPDYの「ストリーム多重化」は、単一のTCP接続の中で、あたかも複数の仮想的なレーンを走らせるような多重化を実現した。
ここで重要なのは、「TCPバッファとストリームの衝突」をどう回避するかだ。
SPDYは一つのTCPセッション上で複数のストリームをインターリーブさせる。もし一つのストリームでパケットロスが発生しても、他のストリームは影響を受けない（※TCP層では接続単位のHOLBは残るが、アプリケーション層のHOLBは解消される）。
ネットワークチューニングの知見
この多重化を最大限活かすためには、Linuxカーネルレベルのチューニングが不可欠だ。TCPウィンドウサイズが小さすぎると、多重化されたストリームがウィンドウを奪い合い、逆にレイテンシが悪化する。
sysctl.conf での設定例
同時並行リクエストが増えるため、送受信バッファを拡張する
net.ipv4.tcp_rmem = 4096 87380 16777216 # 16MBまで拡張
net.ipv4.tcp_wmem = 4096 65536 16777216
TCPの輻輳制御アルゴリズムをBBRに切り替える（モダンな環境の鉄則）
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
—
3. ヘッダー圧縮（HPACKの源流）とTLSの最適化
SPDYはヘッダー圧縮にも切り込んだ。当時のHTTPは、リクエストごとにUser-AgentやCookieを垂れ流していた。SPDYは「DEFLATE」アルゴリズムを用い、ヘッダーの重複を排除した。
そして特筆すべきは、TLSハンドシェイクの最適化だ。SPDYはTLSの上でのみ動作することを前提とし、NPN（Next Protocol Negotiation）を用いてTLSハンドシェイク中にプロトコルを確定させる。これにより、追加のRTT（ラウンドトリップタイム）を発生させずに暗号化通信を確立させることに成功した。
セキュリティ専門家への提言
SPDY/HTTP/2の時代になり、圧縮と多重化が導入されたことで、新たな攻撃ベクター「CRIME」や「BREACH」が浮上した。ヘッダーの圧縮率からコンテンツの内容を推測するサイドチャネル攻撃だ。
- 対策: 重要なセッションIDや機密情報を含むヘッダーは圧縮対象から外す、あるいは適宜パディングを挿入して圧縮率を撹乱する。
- 実装: Nginx等で `gzip` の設定を調整する際は、セキュリティ要件とのトレードオフを必ず評価すること。
—
結びに：次世代への橋渡し
SPDYが提示した「バイナリ」「多重化」「ヘッダー圧縮」という三本の柱は、後にHTTP/2へと昇華された。今やWebはQUIC（HTTP/3）へと移行し、TCPのHOLBすら克服しようとしている。
しかし、なぜ我々が今さらSPDYを語るのか。それは、このプロトコルが「ネットワークの物理的な制約に対し、ソフトウェアがどう立ち向かうべきか」というアーキテクトとしての本質的な思考を教えてくれるからだ。
パケットは嘘をつかない。あなたのサーバーが吐き出す一行のヘッダーが、どれほどの負荷となり、どれほどの遅延を生んでいるのか。その解像度を高めることこそが、真のインフラアーキテクトへの第一歩である。
次は、QUICにおけるUDPマルチプレクシングの深淵を覗いていくとしよう。そこには、また別の「速度の物理学」が待っている。
コメント