途切れたパケットの美学：Rangeヘッダーと「206 Partial Content」が支える巨獣たちの通信最適化
ネットワークエンジニアとして生きていると、ルータのコンソールに流れるルーティングテーブルや、BGPのピア確立の瞬間にロマンを感じるのと同様に、ブラウザとオリジンサーバの間を行き交うHTTPヘッダーのやり取りにも、一種の「美」を見出すことがある。
ギガバイト級のファームウェアバイナリ、4Kのストリーミング動画、あるいは夜間バッチで流し込まれる巨大なデータベースのダンプファイル。これらを単一のTCPストリームで一気に引き込もうとするのは、現代のネットワークトポロジーにおいてあまりにナイーブだ。途中でパケットロスが起き、TCPの輻輳制御がウィンドウサイズを絞り込み、果てはタイムアウトで接続が断たれたとき――最初からすべてをやり直す絶望感を味わったことのあるエンジニアは少なくないはずだ。
この「途方もないサイズのもの」を、人間がカクテルストローで飲むように、あるいは必要な分だけ切り取る外科手術のようにハンドリングする技術が、HTTPの Rangeヘッダー とステータスコード 206 Partial Content である。今回は、このいぶし銀ながら現代のWebインフラを根底から支えるプロトコルのメカニズムを、パケットの挙動、Linuxカーネルのバッファ、そしてセキュリティの観点から深く掘り下げていこう。
—
1. パケットレベルで見るRangeリクエストの解剖学
まずは、クライアントがサーバに対して「このファイルのこの部分だけくれ」と要求する瞬間を、HTTPリクエストのワイヤーフォーマットベースで覗いてみよう。
GET /downloads/huge-firmware-v4.2.0.bin HTTP/1.1
Host: update.example.com
User-Agent: NetworkArch-Client/2.5.0
Range: bytes=0-1048575, 2048000-3145727
Accept-Encoding: gzip, deflate
Connection: keep-alive
このリクエストの肝は、`Range` ヘッダーの指定方法にある。ここでは単一のバイトレンジではなく、`bytes=0-1048575, 2048000-3145727` という マルチパート・レンジ（Multi-range） を指定している。これは「最初から1MBまで」と「約2MBから3MBまで」の2つのチャンクを同時に要求するアグレッシブな構文だ。
これを受けたオリジンサーバ（あるいは前段のリバースプロキシ）が、正常にその範囲を保持しており、リクエストを解釈できた場合、応答のステータスコードは `200 OK` ではなく `206 Partial Content` となる。その時のレスポンスヘッダーの構造は以下のようになる。
HTTP/1.1 206 Partial Content
Date: Thu, 24 Oct 2024 12:00:00 GMT
Server: nginx/1.24.0
Content-Type: multipart/byteranges; boundary=————————1234567890abcdef
Content-Length: 2105432
Connection: keep-alive
————————–1234567890abcdef
Content-Type: application/octet-stream
Content-Range: bytes 0-1048575/52428800
[… 1MB分のバイナリデータ …]
————————–1234567890abcdef
Content-Type: application/octet-stream
Content-Range: bytes 2048000-3145727/52428800
[… 約1MB分のバイナリデータ …]
————————–1234567890abcdef–
ここで注目すべきは、マルチパートレンジの場合、`Content-Type` が `multipart/byteranges` に変わり、ボディ部が境界文字列（Boundary）で区切られた独特のフォーマットに変貌する点だ。各ブロックには個別の `Content-Range` ヘッダーが付与され、「全体で何バイト中のどこからどこか（例: `bytes 0-1048575/52428800`）」が厳密に定義される。
—
2. トランスポート層・カーネル空間における最適化とレジューム機能
インフラアーキテクトとして頭を悩ませるのが、このRangeリクエストを処理する際の ストレージI/Oとカーネルメモリの効率 だ。
巨大なファイルを扱う際、ナイーブな実装ではサーバ側でファイルを一旦メモリ上に読み込んだり、不連続なオフセットに対して `lseek()` を頻繁に発行したりしてディスクのシークネックを誘発する。これを回避するのが、Linuxカーネルの `sendfile()` システムコールや、Nginx等のイベント駆動型アーキテクトによる効率的なゼロコピー（Zero-copy）転送である。
レジューム（中断からの復旧）機能の真価
ファイル転送の途中でTCPコネクションが切断されたとき、クライアントは既存のローカルファイルサイズを起点にRangeを再構築する。
GET /downloads/huge-firmware-v4.2.0.bin HTTP/1.1
Host: update.example.com
Range: bytes=1048576-
`bytes=1048576-` のように終端を指定しないオープンエンドな範囲指定は、「1048576バイト目からファイルの終端まで全て」を意味する。この仕様があるおかげで、HTTPをベースにした堅牢なダウンロードマネージャーや、動画のシークバー移動に伴う動的バッファリングが破綻なく成立しているのだ。
TCPウィンドウとRTT（Round Trip Time）のチューニング
レンジリクエストを多用する環境では、TCPの挙動にも配慮が必要だ。特にモバイル回線や高遅延な衛星通信ネットワークでは、初期のTCPスロースタート（Slow Start）をいかに早く脱却し、BDP（Bandwidth-Delay Product）の限界までスループットを上げられるかが鍵となる。
Linuxサーバー側で以下のようなカーネルパラメータチューニングを行い、TCPバッファの動的チューニングとウィンドウのスケーリングを確実に有効化しておくことが、Rangeリクエストのパフォーマンスを最大限に引き出す前提条件となる。
/etc/sysctl.conf の推奨設定例
TCPの送受信バッファの最小値、デフォルト値、最大値（バイト単位）
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
ウィンドウ スケーリングの有効化（高BDPネットワークでのスループット最大化）
net.ipv4.tcp_window_scaling = 1
選択確認応答（SACK: Selective ACK）の有効化。パケットロス時の再送効率を劇的に改善
net.ipv4.tcp_sack = 1
net.ipv4.tcp_dsack = 1
マルチパートレンジを使用する場合、サーバ側は複数のセグメントを構築して送信するため、SACKが有効であることはパケットロス耐性の面で極めて重要になる。
—
3. セキュリティの暗い影：Range Exhaustion攻撃（DoS）の脅威
プロトコルの便利な機能には、常にセキュリティ上の裏表が存在する。Rangeヘッダーは、悪意ある攻撃者にとって「サーバのリソースを効率的に枯渇させるための極上のツール」になり得る。それが Range Exhaustion攻撃（別名：HTTP Range Amplification Attack / 類似の脆弱性は「Apache Killer」などとしても知られている） だ。
攻撃者は、以下のようなヘッダーを送りつける。
GET /large-file.iso HTTP/1.1
Host: target.example.com
Range: bytes=0-1,0-1,0-1,0-1,0-1,0-1,0-1,0-1,0-1,0-1,0-1,0-1,0-1 … (数千回繰り返し)
もしWebサーバやリバースプロキシが、この数千個に及ぶレンジ指定を愚直にすべて処理し、マルチパートの境界ヘッダーを付与してレスポンスを生成しようとしたらどうなるか？
CPUは膨大な文字列結合処理に奪われ、メモリは断片化し、出力バッファは瞬く間に溢れかえる。これが数千人のボットネットから同時に仕掛けられた場合、堅牢なはずのオリジンサーバは簡単にK.O.される。
対策：Webサーバー・リバースプロキシの防衛設定
この脆弱性やリソース枯渇を防ぐため、インフラエンジニアは必ずゲートウェイ層（NginxやVarnish、あるいはWAF）でRangeリクエストの制限を行わなければならない。
Nginxにおける堅牢な設定例を以下に示す。
http {
# 不正または過剰なRangeリクエストに対する防衛策
# Nginxはデフォルトでも極端なマルチパートレンジを制限するが、モジュールやカスタムマップでさらに厳格化できる
server {
listen 443 ssl http2;
server_name update.example.com;
# TLS設定（省略）…
location /downloads/ {
root /var/www/html;
# 最大許容レンジ数の制限（Nginx標準では約10個を超えるマルチパートは自動的に200 OKにフォールバックするか無視される）
# モジュールやLuaスクリプトを用いて、過剰なレンジを明示的に400 Bad Requestにするのが鉄則
# 例: 特定サイズ以下のファイルに対するRangeを無効化し、無駄なI/Oを防ぐ
max_ranges 20; # 20個以上のレンジ指定は拒否（環境に合わせて調整）
# サーバの過負荷を防ぐためのレートリミット
limit_req zone=download_zone burst=5 nodelay;
}
}
}
また、CDN（CloudflareやCloudFrontなど）を利用している場合、エッジサーバー側でマルチパートレンジを適切に集約・キャッシュ制御してくれるため、オリジンサーバへの直接的な負荷を大幅に軽減できる。しかし、エッジ側でのキャッシュポイズニングや、不適切なRangeキャッシュキーの設計には十分注意が必要だ。
—
4. HTTP/2およびHTTP/3時代におけるRangeヘッダーの変遷
「ストリーム多重化」を実現したHTTP/2以降、Rangeヘッダーの扱いはどう変わったのだろうか。
HTTP/1.1の時代には、同一コネクション内でリクエストとレスポンスが直列化（Head-of-Line Blocking）されていたため、巨大ファイルをダウンロードしながら別の軽いAPIリクエストを流すには、コネクションを複数張る（ブラウザによるドメインあたりのコネクション数制限：通常6個まで）しかなかった。その結果として、マルチパートレンジで強引に並列性を高めるアプローチが重宝された。
しかし、HTTP/2やHTTP/3（QUIC）の世界では、1つのTCP/UDPコネクション上で無数の独立したストリームを完全に並列多重化できる。
そのため、現代のモダンなクライアント（ブラウザや専用ダウンローダー）は、マルチパートの単一リクエストでゴリゴリに分割するのではなく、「別々のストリームで、それぞれ異なる `Range` を指定した単一リクエストを同時並行で発射する」 というアプローチをとるようになった。
[HTTP/2 Connection]
├── Stream ID 1: GET /file.bin (Range: bytes=0-1048575)
├── Stream ID 3: GET /file.bin (Range: bytes=1048576-2097151)
└── Stream ID 5: GET /file.bin (Range: bytes=2097152-3145727)
この方式であれば、HPACK/QPACKによるヘッダー圧縮の恩恵を受けつつ、各ストリームの制御やキャンセル（RST_STREAMフレームによる即座の切断）が極めて容易になる。例えば、ユーザーが動画の再生位置を突然シークさせた場合、HTTP/1.1のマルチパートであればすでに送信中のバッファが無駄になりがちだったが、HTTP/2/3であれば該当するストリームを即座にアボート（RST）し、新しい位置のRangeリクエストを新しいストリームで瞬時に流し込むことができる。プロトコルの進化は、Rangeヘッダーの「使われ方」すらも洗練させてしまったのだ。
—
5. 結びにかえて
Rangeヘッダーと `206 Partial Content` は、HTTPという比較的シンプルでテキストベースのプロトコルが、どれほど柔軟に「物理的なハードウェアの限界（ディスクI/Oやネットワーク帯域）」と渡り合えるかを示す傑出した発明である。
単に「ファイルを分割してダウンロードできる便利なヘッダー」として片付けるのではなく、背後にあるTCPの混雑制御、カーネルのゼロコピー、マルチパートの構文解析、そしてDoS攻撃への耐性までを俯瞰して設計に落とし込むこと。それこそが、我々インフラストラクチャー・アーキテクトに求められる美学であり、プロトコルに対する最大の敬意なのだ。
次にネットワークアナライザやブラウザの開発者ツールで `206` のステータスコードを見かけたときは、その背後で完璧に調律されたパケットのダンスと、カーネルの静かなる躍動に思いを馳せてみてほしい。
コメント