終わりなきストリームの解体新書：HTTP/1.1 `Transfer-Encoding: chunked` の深淵
Webインフラの最前線でパケットを追い続けていると、「なぜ今さらHTTP/1.1のチャンク転送なのか」と問われることがある。だが、答えるまでもない。モダンなHTTP/2やHTTP/3が普及した現在でも、我々が管理する境界プロキシやロードバランサーの背後では、依然としてこの古き良き「非同期ストリーミングの権化」が、動的コンテンツの生命線として蠢いているからだ。
今日は、教科書的な説明を飛び越え、TCPセグメントの断片化からTLSレコードのオーバーヘッドに至るまで、`Transfer-Encoding: chunked` がインフラ層でどのような「血」を流しているのかを解剖していこう。
—
1. チャンク転送という「場当たり的」な必然性
HTTP/1.0の時代、サーバーはコンテンツの全サイズを確定させてからレスポンスを返さねばならなかった。`Content-Length` を送信前に計算するためには、全データをメモリ上にバッファリングする必要があったからだ。これは数GBのログファイルや、リアルタイム生成されるダッシュボードにとって致命的なボトルネックとなる。
ここで登場したのが `Transfer-Encoding: chunked` だ。これは「サイズが不明なまま、とりあえず書き出せる分だけ送る」という、極めてプラグマティックな解決策である。
内部構造のリアル：0\r\n\r\n の重み
チャンク転送のパケット構造はシンプルだ。
1. 16進数によるサイズ指定（例: `400\r\n` は1024バイト）
2. チャンクデータそのもの
3. CRLF (`\r\n`)
これの繰り返しであり、終了時にはサイズが `0` のチャンク（終了チャンク）を送ることで、受信側に「これでストリームは完結した」と告げる。
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
5\r\n # 16進数で5バイト
Hello\r\n # 実データ
0\r\n # 終了チャンク
\r\n # 終了シーケンス（重要！）
—
2. インフラ・エンジニアが直視すべき「コスト」
チャンク転送は魔法ではない。裏側では、トランスポート層に特有の負荷がかかっている。
TCPバッファとセグメンテーションの罠
チャンクサイズが小さすぎると、TCPの `MSS (Maximum Segment Size)` を効率的に使い切れない。一方で大きすぎると、サーバー側のメモリ消費を圧迫し、アプリケーション層のレスポンス待ちでTCPウィンドウがスタックする。
特に、バックエンドからプロキシへ流れるチャンクのサイズが、`tcp_rmem` / `tcp_wmem` と不一致を起こすと、不必要なACKの往復が発生し、RTT（往復遅延時間）を悪化させる原因となる。
TLSとの共犯関係
TLSを使用している場合、チャンク転送はさらに複雑な「レコード」の断片化を引き起こす。TLSレコードはそれ自体がメタデータを持つため、極小のチャンクを頻発させると、暗号化オーバーヘッドの比率が跳ね上がり、CPUサイクルを無駄に消費する。
理想は、「TLSレコードサイズ（通常16KB）に収まるようなチャンク単位での書き込み」をアプリケーション層で制御することだ。
—
3. セキュリティの急所：HTTP Request Smuggling
プロキシ環境下で最も恐ろしいのは、`Transfer-Encoding` と `Content-Length` の解釈の不一致を突いた「HTTP Request Smuggling」だ。
フロントエンドのプロキシが `Transfer-Encoding` を無視し、バックエンドがこれを解釈する場合、攻撃者は悪意のあるリクエストを後続のリクエストに「混入」させることができる。
対策の鉄則：
- モダンなゲートウェイ（Nginx, HAProxy等）では、曖昧なヘッダーを持つリクエストを即座に破棄せよ。
- `Transfer-Encoding` と `Content-Length` が両方存在する場合は、迷わず400 Bad Requestを返す。
Nginxでの対策例
曖昧なリクエストをブロックする設定
if ($http_transfer_encoding ~ “chunked”) {
# chunkedが指定されている場合はContent-Lengthを無視するように徹底
# 実際にはプロキシ層での厳格なバリデーションが必須
}
—
4. チューニングの極意：RTT削減へのアプローチ
チャンク転送において、パフォーマンスを最大化するために私が現場で必ず確認するポイントを記しておく。
1. バッファリング戦略の最適化
- Nginxであれば `proxy_buffering on;` を活用せよ。バックエンドからのチャンクを一度バッファに蓄え、ある程度サイズが溜まってからクライアントへ送出することで、クライアント側の低速なネットワークの影響をバックエンドに伝播させない。
2. TCP_NODELAYの適用
- リアルタイム性が求められるストリームの場合、`TCP_NODELAY` を有効にし、Nagleアルゴリズムによる不要な待機時間を排除する。
3. HTTP Keep-Aliveの維持
- チャンク転送はKeep-Aliveの文脈で初めて真価を発揮する。コネクションを再利用し、TLSハンドシェイクのオーバーヘッドをゼロに近づけることが、結果として最も高いパフォーマンス改善を生む。
—
結びに代えて
`Transfer-Encoding: chunked` は、Webの黎明期から続く、非常に泥臭く、しかし極めて強力な「パイプライン」だ。パケットの深層に潜るエンジニアであれば、単に「動く」ことを喜ぶのではなく、それがネットワークの帯域をどう使い、サーバーのCPUをどう回転させているのかを常に意識してほしい。
プロトコルは、常に我々の直感よりも少しだけ狡猾に動く。だが、その挙動を手に取るように理解した時、ネットワークは初めて君たちの意のままに操れる「楽器」に変わるはずだ。
次は、このチャンクデータがどのようにHTTP/2のフレーム構造へと「変換」され、あるいは「吸収」されるのか……その辺りの話を深掘りするとしようか。
コメント