終わりの見えないデータストリームを制御せよ：HTTP/1.1 `Transfer-Encoding: chunked` の深淵
Webインフラの最前線に立つエンジニアにとって、HTTP/1.1の`Transfer-Encoding: chunked`は、単なる「コンテンツ長が不明な時の回避策」ではない。それは、動的に生成されるコンテンツと、TCPのストリーム志向という、本来相容れない二つの世界を繋ぐための、古くからあるが極めて強力な「調整弁」だ。
今日は、このレガシーな技術がいかに現代のハイパフォーマンスなネットワークアーキテクチャに影響を与えているか、パケットレベルの挙動を紐解きながら深掘りしていこう。
—
なぜ「長さ」を伏せる必要があるのか
通常、HTTPレスポンスには `Content-Length` ヘッダーがつく。ブラウザやプロキシはこれを見てバッファを確保し、パケットの到着を待ち受ける。しかし、バックエンドで生成に時間がかかるストリーミングデータや、DBのクエリ結果を逐次流し込むようなケースでは、全コンテンツのサイズを事前に計算することは不可能だ。
ここで登場するのが `Transfer-Encoding: chunked` だ。データを一塊（チャンク）ごとに分割し、各チャンクの先頭に「16進数で記述したサイズ」を付与することで、受信側に「次はこれだけ来るぞ」とあらかじめ伝達する。
構造の解剖：パケットレベルのリアル
チャンク転送の構造は、極めてシンプルだが美しい。
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
5\r\n # 16進数のサイズ（5バイト）
Hello\r\n # 実際のデータ
3\r\n # 次のチャンクサイズ（3バイト）
Web\r\n # 実際のデータ
0\r\n # 終端を示す0チャンク
\r\n # 最後のエンプティ行
注目すべきは、最後の `0\r\n\r\n` だ。これがストリームの終端を告げるシグナルとなる。ここが壊れると、クライアントは接続が切断されるまで待ち続ける（あるいはタイムアウトする）ことになり、インフラエンジニアにとっての「悪夢のデバッグ」が幕を開けるわけだ。
—
パフォーマンスチューニング：TCPバッファとRTTの最適化
`chunked` 転送を行う際、我々が最も警戒すべきは「チャンクサイズが小さすぎること」によるオーバーヘッドだ。
各チャンクにはヘッダー（サイズ情報）が付与される。もし100バイトごとにチャンクを区切れば、ネットワーク上のプロトコルオーバーヘッドが激増し、TCPのセグメンテーション効率が悪化する。
カーネルパラメーターの最適化
高負荷なWebサーバーにおいて、チャンク転送を効率化するには、TCPのバッファ管理が鍵となる。
sysctl.conf でのTCPバッファ調整例
ストリーミングが頻発する場合、送信バッファを広めに確保する
net.ipv4.tcp_wmem = 4096 65536 16777216
Nagleアルゴリズムによる遅延を防ぐため、TCP_NODELAYを意識しつつ
適切なMTUでセグメントを構築する
ここで重要なのは、アプリケーションレイヤーでの「バッファリング戦略」だ。小さすぎるチャンクを頻繁に投げると、TCPのACK待ちによるRTT（Round Trip Time）の累積で、レスポンスのTTFB（Time To First Byte）が著しく悪化する。「チャンクサイズは可能な限りTCPのMSS（Maximum Segment Size）に同期させる」のが鉄則だ。
—
セキュリティの急所：HTTP Request Smuggling
セキュリティ専門家として看過できないのが、「HTTP Request Smuggling（リクエストスマグリング）」の脆弱性だ。
`Transfer-Encoding` と `Content-Length` が同時に送られてきた場合、フロントエンドのロードバランサー（L7）とバックエンドのサーバー（L7）が、どちらを優先してパースするかで挙動が食い違う。攻撃者はこの隙を突き、悪意のあるリクエストを後続の通信に潜り込ませる。
回避策の要点
1. 正規化の徹底: WAFやリバースプロキシ（Nginx/Envoy）で、矛盾するヘッダーを持つリクエストを即座に拒否すること。
2. HTTP/2以降への移行: `chunked` のようなあいまいな境界検知を排除し、バイナリフレームで長さを厳密に管理するプロトコルへの移行を強く推奨する。
—
現代のアーキテクチャへの教訓
現代のインフラでは、`chunked` はHTTP/2の「ストリームマルチプレキシング」や、gRPCの「Server-side Streaming」の基礎概念として生きている。
かつてHTTP/1.1で苦労した「チャンクの終端検知」や「ストリームの中断処理」は、現代のプロトコルではフレームサイズとして厳格に定義されている。しかし、上位プロトコルがどれほど進歩しても、物理層でパケットが断片化され、TCPウィンドウが揺らぐ現実が変わることはない。
私たちが学んだ「チャンク」の教訓は、「データの境界を誰がどう定義するか」という、プロトコル設計における最も根源的な問いに対する答えだ。
次に `Transfer-Encoding: chunked` を目にしたとき、単なるテキストではなく、背後にあるカーネルのバッファリングと、ネットワークのRTT、そしてその先にある脆弱性の可能性を想像してほしい。それこそが、世界最高峰のインフラアーキテクトへの第一歩だ。
コメント