終わりのないデータとの対峙：HTTP/1.1 `Transfer-Encoding: chunked` の深淵
Webの進化の歴史を紐解くと、HTTP/1.1が果たした役割は単なる「コネクション維持（Keep-Alive）」だけではない。特に「動的なコンテンツを、全貌が見えないまま送り出す」という、当時のエンジニアにとっての切実な課題を解決したのが `Transfer-Encoding: chunked` だ。
今日は、教科書的な解説を一歩踏み越え、TCPスタックの挙動やバッファ戦略、そしてセキュリティという視点から、この「断片化された転送」の正体に迫る。
—
なぜ「Chunked」が必要だったのか：Content-Lengthの限界
HTTP/1.0の頃、クライアントがコンテンツの終わりを検知する唯一の方法は「コネクションの切断（FINパケットの受信）」だった。しかし、これでは毎回TCPの3ウェイハンドシェイクとスロースタートを繰り返すことになり、Webの体験は壊滅的になる。
かといって、`Content-Length` を指定しようとすれば、サーバーはコンテンツを完全に生成し終え、そのサイズを計算し終えるまでレスポンスを返せない。バックエンドで複雑なDBクエリを回しながら、最初の1バイトをクライアントに届けたい――そんなストリーミング時代の要求に応える解が、チャンク転送だ。
チャンク転送の内部構造：パケットの解剖学
`Transfer-Encoding: chunked` を有効にすると、レスポンスボディは複数の「チャンク」に分割される。各チャンクは以下の形式で送出される。
[チャンクサイズ（16進数）]\r\n
[チャンクデータ]\r\n
[チャンクサイズ（16進数）]\r\n
…
0\r\n
\r\n（トレーラーヘッダーがあればここに記述）
特筆すべきは、最後に送られる `0\r\n\r\n` という終端シグナルだ。この「0」を受け取った瞬間に、クライアントのパーサーは「あ、これ以上は待たなくていい」と判断し、後続の処理（描画や次リクエストの送出）を開始する。
実践：Node.jsで見るストリームの挙動
以下は、この仕組みを意図的に利用した擬似的なストリーム生成コードだ。
// サーバー側：チャンクを意図的に小分けにして送出する
res.writeHead(200, {
‘Content-Type’: ‘text/html’,
‘Transfer-Encoding’: ‘chunked’ // これによりチャンク転送が開始される
});
// 1秒ごとに断片を送る。TCPバッファが満杯になるのを待たずにパケットを押し出す
setInterval(() => {
res.write(‘{“status”: “processing”, “timestamp”: ‘ + Date.now() + ‘}\n’);
}, 1000);
パフォーマンスとチューニングの深淵
インフラアーキテクトとして注目すべきは、これがTCPの輻輳制御とどう絡むかだ。
- TCPバッファチューニング: `chunked` を使う場合、小さなチャンクを頻発させると、TCPの `Nagleアルゴリズム` によってACK待ちが発生し、逆に遅延（レイテンシ）を増大させることがある。Linuxサーバーであれば、`TCP_NODELAY` オプションを有効にし、アプリケーション層で制御されたサイズのパケットを即座にネットワークへ流し込む設計が定石だ。
- TLSハンドシェイクとの共生: HTTP/1.1のボトルネックはTLSのオーバーヘッドにある。チャンク転送はストリームの一部であるため、TLSのレコードサイズが不適切だと、レコードが断片化され、パケットロス時のリカバリ効率が落ちる。TLSのレコードサイズをMTUに合わせて最適化することは、高負荷環境では必須のチューニングだ。
潜むリスク：HTTP Request Smuggling
ここでセキュリティの観点から警告しておきたい。`Transfer-Encoding: chunked` は、Webのフロントエンド（リバースプロキシ）とバックエンド（アプリケーション）の解釈のズレを突く「HTTPリクエストスマグリング」の温床となり得る。
もしフロントエンドが `Transfer-Encoding` を無視し、バックエンドがこれを処理する場合、攻撃者は不正なチャンク長を送り込み、後続のリクエストを「次のリクエスト」として誤認させ、キャッシュ汚染やセッションジャックを引き起こす。
対策:
1. プロキシとバックエンドの間で、HTTPプロトコルのバージョンを厳格に固定する。
2. 曖昧なヘッダー（`Transfer-Encoding` と `Content-Length` の両方が存在するリクエスト）は即座に破棄する。
3. WAFでチャンクサイズが異常に大きくないか監視する。
結びに：モダンなWebへの教訓
HTTP/2やHTTP/3（QUIC）が普及した現代でも、`chunked` の哲学は生きている。HTTP/2のストリーム多重化は、いわば「論理的なチャンクを並列で転送する」仕組みに他ならないからだ。
ネットワークプロトコルは、単なるデータの運び屋ではない。いかにして「非同期な世界」と「同期的なクライアント」を繋ぐか。その歴史的格闘の跡が、この `0\r\n\r\n` という小さな終端文字に凝縮されている。
次回のデバッグ時、パケットキャプチャツールでこの「0」を見かけたら、その向こう側にある膨大な計算資源と、それを繋ぐエンジニアたちの苦悩に思いを馳せてみてほしい。ネットワークは、常に詳細の中にこそ真実が隠れているのだから。
コメント