HTTP/1.1の「職人芸」：Rangeヘッダーが支えるレジュームと部分転送の深淵
Webエンジニアの皆さん、こんにちは。日々のログ解析やパケットキャプチャで、`206 Partial Content`というステータスコードに救われた経験は何度ありますか？
私たちは普段、ブラウザのURLバーにアドレスを叩き込み、ページが「パッと」表示されることを当然だと思っています。しかし、動画のシークバーを動かした瞬間や、大容量ファイルのダウンロードが中断されても再開できるのは、HTTP/1.1の仕様において非常にエレガントに実装された「Range」という仕組みのおかげです。
今回は、教科書的な説明は最小限に、現場でトラブルシューティングに役立つ「Rangeリクエストのリアル」を掘り下げていきましょう。
—
1. なぜ「全件取得」だけではいけないのか
HTTP/0.9や1.0の時代、リクエストは基本的に「ファイル全体をください（GET /file.zip）」という非常にシンプルなものでした。しかし、現代のような巨大なバイナリデータや高解像度の動画を扱う世界では、この仕様は非効率の極みです。
例えば、1GBの動画の最後5秒だけを見たい場合、あるいはネットワークが不安定でダウンロードが途切れた場合、いちいち最初から再取得していては帯域と時間の無駄ですよね。ここで登場するのが `Range` ヘッダーです。
通信の裏側で起きていること
クライアントが `Range: bytes=0-1023` とヘッダーを付与してリクエストを送ると、サーバーは「あ、全部じゃなくて最初の一部だけ欲しいのね」と理解し、以下の応答を返します。
- ステータスコード: `206 Partial Content`
- Content-Range: `bytes 0-1023/1048576` （全体のサイズが1MBであることを示唆）
この「206」こそが、サーバーがクライアントの要求を正しく解釈し、指定された部分だけを切り出して送ったという「信頼の証」なのです。
—
2. 実務で使う：curlとコードによる検証
理論だけでは現場は動きません。まずは `curl` を使って、サーバーがRangeリクエストを受け付けているか（`Accept-Ranges`ヘッダーがあるか）を確認する癖をつけましょう。
curlでの確認例
-Iでヘッダーのみを取得し、Accept-Rangesを確認する
curl -I https://example.com/large-file.mp4
もし「Accept-Ranges: bytes」と返ってくれば、そのサーバーは部分リクエストをサポートしている
次に、Pythonを用いて指定範囲のデータだけを抽出する簡単なスクリプトを書いてみます。
import requests
url = “https://example.com/large-file.mp4″
最初の1MBだけを取得するリクエスト
headers = {‘Range’: ‘bytes=0-1048575’}
response = requests.get(url, headers=headers)
if response.status_code == 206:
print(f”成功: {len(response.content)} バイト取得完了”)
# ここでファイルに追記（append）していく処理を書けばレジューム機能になる
else:
print(f”失敗: ステータスコード {response.status_code}”)
—
3. インフラ担当者が知っておくべき「落とし穴」
このRangeリクエスト、実はCDNやプロキシサーバーとの組み合わせで「ハマりポイント」になりがちです。
Tips 1: キャッシュキーの注意点
CDN（CloudFrontやFastlyなど）を利用している場合、`Range`ヘッダー自体がキャッシュのバリエーション（Vary）に含まれているか確認してください。もしキャッシュの設定が甘いと、誰かが中途半端なRangeリクエストを送った結果、その「断片」がキャッシュされてしまい、他のユーザーにも断片データが配信されるという悲劇（キャッシュ汚染）が起きることがあります。
Tips 2: Nginxの設定を確認する
もしあなたがNginxで静的ファイルを配信しているなら、デフォルトで `max_ranges` 設定が有効になっています。攻撃者がRangeヘッダーを大量に送りつけてサーバーリソースを枯渇させる（Range-based DoS）を避けるため、以下の設定値は適切に管理しましょう。
Nginx設定ファイル例
http {
# 1リクエストあたりのRangeヘッダーの許容数
max_ranges 5;
# 転送時の断片化を制御（必要に応じて調整）
output_buffers 1 128k;
}
—
4. 最後に：デバッグの心得
現場で「なぜかファイルが最後までダウンロードできない」「シークが効かない」という相談を受けたとき、私はまずブラウザの「開発者ツール（Networkタブ）」を開きます。
1. Request Headerに `Range` が含まれているか？
2. Response Headerに `Content-Range` があるか？
3. HTTPステータスは `200 OK` になっていないか？（※サーバーがRangeを無視すると、いきなり全データを送り始めます。これは致命的な帯域浪費です）
HTTP/1.1の仕様は歴史が長い分、非常に堅牢です。しかし、その仕様を正しく理解し、サーバー側の設定とクライアント側の挙動をパケットレベルで把握できて初めて、エンジニアとしての「道具」になります。
明日のトラブルシューティングでは、ぜひ `206 Partial Content` の裏にあるサーバーの優しさに思いを馳せながら、`curl` を叩いてみてください。それでは、良いネットワークライフを。
コメント