なぜ「全部」受け取る必要があるのか？：HTTP/1.1 Rangeリクエストが支える現代の通信効率
インフラの現場でパケットを追いかけていると、時折「なぜこんなに無駄な転送をしているんだ？」と頭を抱えたくなる瞬間がある。数ギガバイトの動画ファイルや、巨大なログファイルをダウンロードする際、ネットワークが瞬断して最初からやり直し……。もし現代のWebがHTTP/0.9のような「全か無か」の世界だったら、私たちのインフラはとっくの昔にパンクしていただろう。
今回は、HTTP/1.1の隠れた功労者である「Rangeリクエスト」と、それに呼応するステータスコード「206 Partial Content」について、現場の視点から掘り下げていこう。
Rangeリクエスト：要求の「断片化」という知恵
Rangeリクエストの概念は極めてシンプルだ。クライアントがサーバーに対して「ファイルのこの位置から、この位置までのデータだけをくれ」と要求する。これを実現するのが `Range` ヘッダーだ。
通信シーケンスのリアル
1. クライアント: `Range: bytes=0-1023` とリクエスト（最初の1KBを要求）
2. サーバー: 該当ファイルがサポートしていれば、`206 Partial Content` を返し、`Content-Range` ヘッダーで「全体のうちどこを送っているか」を明示する。
3. 終了: もしサーバーが `Accept-Ranges: bytes` をレスポンスヘッダーで返していれば、そのサーバーはRangeリクエストを受け入れ可能だというサインだ。
実践：curlで覗く「206」の裏側
座学よりもまずはパケットだ。`curl`を使って、特定の範囲だけを取得してみよう。
-Iでヘッダーを確認、-rで範囲を指定
bytes=0-499 は、ファイルの最初の500バイトを要求するという意味
curl -I -r 0-499 http://example.com/large-file.mp4
ここで返ってくるレスポンスヘッダーには、重要な情報が含まれている。
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Range: bytes 0-499/10485760 # 全体10MBのうち、0〜499バイトを返す
Content-Length: 500 # ここが重要：全体ではなく、送った断片のサイズ
この `Content-Length: 500` がポイントだ。もしここがファイルの全長になっていたら、それはただの「200 OK」の誤用か、実装ミスである可能性が高い。トラブルシューティングの際、まずはこの `Content-Length` と `Content-Range` の整合性を疑うのが、ベテランの定石だ。
Web APIでの実装：Python (Requests) での活用
Web APIを設計する際、例えば動画ストリーミングや、巨大なバイナリファイルを扱うプロキシサーバーを作るなら、このRange処理を正しく実装する必要がある。
import requests
特定の範囲を指定してダウンロード（レジューム機能の基本）
url = “http://example.com/data.bin”
headers = {‘Range’: ‘bytes=1024-2047’} # 1KB〜2KBの間を要求
response = requests.get(url, headers=headers)
if response.status_code == 206:
print(f”成功: {len(response.content)} バイトを受信しました”)
else:
print(f”失敗: ステータスコード {response.status_code}”)
運用上の注意点：ここが「現場の落とし穴」だ
Rangeリクエストを扱う際、インフラエンジニアとして注意すべき点がいくつかある。
- キャッシュサーバーの罠: CDNやリバースプロキシ（Nginx/Varnish）がRangeリクエストを正しく解釈できない場合がある。特にキャッシュが「ファイル全体」をキャッシュしているか、「断片」をキャッシュしているかで挙動が変わるため、`Vary: Range` ヘッダーの扱いには細心の注意を払うこと。
- 動的な生成コンテンツ: プログラムで動的に生成したコンテンツに対してRangeをサポートさせるのは骨が折れる。`Content-Length` を正確に計算し、かつ `Accept-Ranges` を正しく送出できているか、CI/CDでテストケースを組んでおくことを強く推奨する。
- バリデーション: `If-Range` ヘッダーを活用せよ。ファイルの更新日時（ETagやLast-Modified）が変わった場合、クライアントが持っている断片は無効になる。これを無視すると、不整合なデータが結合されるという「悪夢」が待っている。
結びに代えて
HTTP/1.1のRangeリクエストは、単なる機能ではない。それは、不安定なインターネットという「回線」の上で、いかに効率的かつ堅牢にデータを運ぶかという、先人たちの執念の結晶だ。
もし今、あなたのAPIが「巨大なファイルのダウンロード中に切断される」というクレームを受けているなら、まずはRFC 7233を紐解き、Rangeリクエストが正しくハンドリングされているか、サーバーのログを眺めてみてほしい。パケットは嘘をつかない。そこには必ず、解決のヒントが隠されているはずだ。
次に現場で「206」のステータスを見たとき、ただの数字としてではなく、データが細切れになって最適に流れている姿をイメージしてほしい。それが、一流のネットワークエンジニアへの第一歩だ。
コメント