巨大なファイルを「つまみ食い」する技術：Rangeヘッダーと206 Partial Contentの深層
ネットワークの世界で、「すべてか、無か」という二択はあまりにも無慈悲だ。GB単位の動画ファイルや、巨大なログファイルをダウンロードしている最中に回線が瞬断したとき、最初からやり直しを命じられた経験はないだろうか？
HTTP/1.1で導入された`Range`ヘッダーと`206 Partial Content`は、まさにそんな絶望を救うための「外科手術用メス」のような仕組みだ。今回は、このプロトコルの挙動をエンジニアの視点で解剖していこう。
—
1. なぜ「一部だけ」が必要なのか？
HTTPの基本は「リソース全体を要求する」ことだ。しかし、Webアプリケーションやモバイルインフラの現場では、以下の要件が不可欠になる。
- レジューム機能: 中断されたダウンロードを、切れた場所から再開する。
- ストリーミング: 動画プレイヤーが、ファイルの先頭からではなく、シークバーで指定した位置から読み込む。
- 効率的なデータ取得: 巨大なバイナリファイルのメタデータだけをヘッダーから抽出する。
これらを実現するのが、クライアントから送られる `Range` ヘッダーと、それに対するサーバーの `206 Partial Content` という応答だ。
—
2. 通信フローの解剖：シーケンスの裏側
クライアントが「ファイルの後半だけ欲しい」と要求したときの、HTTPパケットのやり取りを見てみよう。
クライアントからのリクエスト
GET /large-video.mp4 HTTP/1.1
Host: example.com
Range: bytes=1048576-2097151 # 1MBから2MBまでの範囲を要求
サーバーからの応答
HTTP/1.1 206 Partial Content
Content-Type: video/mp4
Content-Range: bytes 1048576-2097151/10485760 # 全体10MBのうち、この部分であるという明示
Content-Length: 1048576 # 返却するバイト数
…
[バイナリデータ…]
ここでのポイントは、`Content-Range` ヘッダーだ。これがないと、クライアントは「今受け取ったデータが全体のどこに位置するのか」を正しく連結できない。インフラエンジニアとしてデバッグする際は、まずこのヘッダーが正しく生成されているかを `curl -I` で確認するのが定石だ。
—
3. 実践：curlとPythonで「つまみ食い」を体験する
理論だけでなく、実際に手を動かして挙動を確認しよう。
curlでRangeリクエストを投げる
特定のバイト範囲を抜き出して保存するコマンドだ。
1MBから1024バイト分だけ取得してファイルに保存
curl -r 1048576-1049599 http://example.com/large-file.bin -o partial.bin
Python (Requests) で実装する場合
API設計において、クライアント側で再開処理を実装する際のロジックはこうなる。
import requests
url = “http://example.com/large-file.bin”
既に5MBダウンロード済みと仮定
start_byte = 5 1024 1024
headers = {‘Range’: f’bytes={start_byte}-‘}
response = requests.get(url, headers=headers)
if response.status_code == 206:
with open(“large-file.bin”, “ab”) as f: # 追記モードで保存
f.write(response.content)
print(“続きのデータの取得に成功しました”)
else:
print(f”サーバーがRangeリクエストをサポートしていません: {response.status_code}”)
—
4. 現場のトラブルシューティングTips
最後に、シニアエンジニアとして知っておいてほしい「ハマりどころ」を共有する。
1. Accept-Rangesヘッダーの有無:
サーバーが `Range` リクエストを受け付ける場合、必ずレスポンスヘッダーに `Accept-Ranges: bytes` を含める必要がある。これがなければ、クライアントは再開処理を諦めることになる。
2. CDNとキャッシュの罠:
CDN（CloudFrontやFastlyなど）を通している場合、キャッシュサーバーが `Range` リクエストを正しくオリジンへ転送しているか確認が必要だ。古いCDN構成では、Rangeリクエストを無視して「200 OK」で全データを返してくるケースがある。
3. 複数範囲のリクエスト（Multipart Range）:
`Range: bytes=0-100, 200-300` のように、複数の範囲を一度に要求することも可能だが、サーバー側での処理が複雑化するため、実装には十分な注意が必要だ。クライアント側が対応していないことも多いため、基本的には範囲を分割して個別にリクエストを送るのが無難だ。
—
まとめ
`Range` ヘッダーは、現代のWebインフラを支える縁の下の力持ちだ。仕様書（RFC 9110）を読み込むのも大切だが、まずは手元の `curl` でレスポンスコードが `206` になる瞬間を目撃してほしい。
プロトコルは、パケットの流れを想像できた瞬間に、ただの文字の羅列から「意思を持った対話」に変わる。君たちのWeb APIが、どんなネットワーク環境下でもタフに振る舞えるよう、この小さなヘッダーの力をぜひ活用してほしい。
コメント