帯域と時間の魔術師：HTTP/1.1 Rangeリクエストと206 Partial Contentの深淵
ネットワークの現場にいると、「なぜかダウンロードが途中で切れる」「動画のシークバーを動かした瞬間に読み込みが止まる」といった相談を耳にすることがあります。Web APIを設計する際、あるいは大規模なフロントエンドを構築する際、私たちが何気なく使っている「ブラウザの戻るボタン」や「動画プレイヤー」の裏側で、HTTP/1.1の隠れた功労者であるRangeリクエストがどのような魔法をかけているか、意識したことはありますか？
今回は、通信インフラの視点から、この「部分取得」という強力な武器を解剖していきます。
—
1. なぜ「全部」受け取る必要があるのか？
HTTP/1.0の頃、Webは「全か無か」の世界でした。ファイルを要求すれば、サーバーは必ずファイルの先頭から終端までをすべて送り届ける必要がありました。しかし、数ギガバイトの巨大なOSイメージや、シーク可能な動画ファイルを扱う現代において、この仕様はあまりに非効率です。
ここで登場するのが、HTTP/1.1で標準化されたRangeヘッダーです。これを使うことで、クライアントは「ファイルの〇〇バイト目から△△バイト目までだけをくれ」とサーバーに交渉できるようになります。
通信シーケンスの核心
この通信の肝は、サーバーが返す206 Partial Contentというステータスコードです。
1. Client: `Range: bytes=0-1023` （最初の1KBを要求）
2. Server: `206 Partial Content` + `Content-Range: bytes 0-1023/5000` （「要求通り、5000バイト中の最初の1KBを送るよ」という宣言）
このやり取りのおかげで、ネットワーク帯域を無駄に消費せず、クライアントは必要な部分だけをピンポイントで引き抜けるのです。
—
2. 現場で使える「Range」の書き方
実務でRangeを操作する場合、以下のパターンを頭に入れておくとデバッグが劇的に楽になります。
- `bytes=0-499`: 0から499バイト目まで（最初の500バイト）
- `bytes=500-999`: 500から999バイト目まで
- `bytes=-500`: 最後の500バイト（「後ろから500バイト」を要求する際に重宝します）
- `bytes=1000-`: 1000バイト目から最後まで
実践：curlで挙動を確認する
トラブルシューティング時、まずはcurlでサーバーがRangeをサポートしているか確認するのが鉄則です。
サーバーがAccept-Rangesヘッダーを返しているかチェック
curl -I https://example.com/large-video.mp4
もし「Accept-Ranges: bytes」が返ってくれば、Rangeリクエストを受け入れ可能です
実際に先頭の100バイトだけを取得してみる
curl -H “Range: bytes=0-99” -o output.bin https://example.com/large-video.mp4
—
3. Web API開発での注意点：サーバー実装の落とし穴
Node.jsやGoで独自にファイル配信サーバーを書く場合、単にRangeヘッダーを解釈するだけでは不十分です。以下の点に注意してください。
- Accept-Rangesヘッダーの付与: サーバー側で `Accept-Ranges: bytes` をレスポンスヘッダーに含めないと、クライアント（ブラウザ）はRangeリクエストを送ってこないことがあります。
- Content-Rangeの正確な計算: `Content-Range: bytes 0-499/10000` のように、全体のサイズ（この例では10000）を必ず記載してください。これが欠けると、クライアントはダウンロードの完了判定ができず、いつまでも接続を維持しようとしてタイムアウトします。
- If-Rangeの考慮: キャッシュの整合性を保つため、リソースが更新されていないか確認する `If-Range` ヘッダーの実装も推奨されます。
—
4. フロントエンドから操作する（Fetch API）
モダンなフロントエンド開発において、巨大なバイナリデータをストリーミング的に処理する場合、Fetch APIでRangeを注入します。
async function fetchPartialData(url, start, end) {
const response = await fetch(url, {
headers: {
// 必要な範囲を指定
‘Range’: `bytes=${start}-${end}`
}
});
if (response.status === 206) {
const blob = await response.blob();
console.log(`取得成功: ${blob.size}バイト`);
return blob;
} else {
throw new Error(‘206 Partial Contentではありません’);
}
}
—
最後に：ネットワークアーキテクトからのアドバイス
Rangeリクエストは一見単純ですが、CDNやプロキシサーバーを挟む環境では注意が必要です。キャッシュサーバーがRangeリクエストを正しく理解していない場合、キャッシュヒットせずにオリジンサーバーへリクエストが突き抜けてしまい、負荷軽減の恩恵を受けられないことがあります。
また、セキュリティ面では、不特定多数のRangeリクエストを許容すると、サーバーのディスクI/Oを意図的に酷使する「Range攻撃（DoS攻撃の一種）」に悪用されるリスクもあります。大規模なサービスを公開する際は、必ずCDN（CloudFrontやFastlyなど）のキャッシュ設定を見直し、必要に応じてレート制限をかけることを忘れないでください。
プロトコルは、単なるルールの集まりではありません。それは、私たちが限られたネットワークリソースをいかに賢く、そして美しく使いこなすかの「知恵」そのものです。皆さんのコードが、今日も効率的にパケットを運ぶことを願っています。
コメント