巨大な荷物を一度に受け取るのは無理！「Rangeリクエスト」で賢く通信しよう
こんにちは！ネットワークの世界へようこそ。
皆さんは、スマホで映画を観ているとき、読み込み途中で止まってしまった経験はありませんか？あるいは、巨大なファイルをダウンロード中に回線が切れて、「最初からやり直し…」と絶望したことはないでしょうか。
実は、HTTP/1.1という規格には、そんな悲劇を防ぐためのとても賢い仕組みが用意されています。それが「Range（レンジ）リクエスト」と「206 Partial Content」です。
今日は、この「必要な分だけ切り取って受け取る」というスマートな通信の裏側を、郵便配達に例えて紐解いていきましょう！
—
1. 普通の通信は「一冊まるごと配送」
まずは、Webサーバーからファイルを受け取る「普通」の状態を考えてみましょう。
あなたがWebブラウザで画像や動画を要求するとき、サーバーは「はい、どうぞ！」と言って、そのファイル全体をドンと渡してくれます。
- 200 OK: 「ファイル全部用意したよ！」という合図
- 配送状況: 100MBの動画なら、100MBすべてを一度に送る
もし途中で回線が切れたら？最初からやり直しです。これは、1000ページの辞書を注文したのに、配送中に一度でも転んだら、また最初から全部配り直しになるのと同じくらい非効率ですよね。
—
2. Rangeヘッダーは「ここからここまで」の指示書
ここで登場するのが「Range（範囲）リクエスト」です。
これは、クライアント（あなたのスマホやPC）がサーバーに対して、「ファイル全部はいらないから、0バイト目から500バイト目までだけちょうだい！」とピンポイントでお願いする仕組みです。
郵便で例えるなら、「辞書の第1章だけでいいので、そこだけ抜き出して送ってください」と付箋を貼るようなイメージですね。
ブラウザが送る指示書（リクエストヘッダー）の例
GET /movie.mp4 HTTP/1.1
Host: example.com
Range: bytes=0-499 # ここが「最初の500バイトだけちょうだい！」という指示です
—
3. 「206 Partial Content」はサーバーからの「了解、一部配送するよ」
サーバーはこのリクエストを受け取ると、「全部送るわけじゃないけど、指定された場所ならあるよ！」と返事をします。この時に返されるのが「206 Partial Content」です。
200 OKが「全部入り」なら、206は「一部だけ抽出したよ」というステータスコードです。
サーバーからの返事（レスポンスヘッダー）の例
HTTP/1.1 206 Partial Content
Content-Type: video/mp4
Content-Range: bytes 0-499/10000 # 「全10000バイトのうち、0〜499バイトを送るよ」
Content-Length: 500 # 「今送ったのは500バイト分だよ」
このやり取りのおかげで、動画プレイヤーは「最初の5秒だけ」をすぐに再生でき、残りは後からゆっくりダウンロードする、といった賢い芸当ができるようになるのです。
—
4. なぜこれが「レジューム（中断再開）」に効くのか？
この仕組みの最大のメリットは、「続きから再開できること」です。
もしダウンロードが900バイト目で止まってしまったらどうなるでしょうか？
次にブラウザが送るリクエストはこうなります。
GET /movie.mp4 HTTP/1.1
Range: bytes=900- # 「900バイト目以降を全部ちょうだい！」
サーバーは「了解！」と、900バイト目以降のデータだけを送ってくれます。こうして、私たちは最初からダウンロードし直す苦労から解放されるわけです。
—
最後に：ネットワークを「優しく」使う技術
Rangeリクエストは、単なるダウンロードの効率化だけではありません。サーバーにとっても「一度に全データをメモリに乗せて送る」負荷を減らせるため、Webサイト全体のレスポンスを向上させる重要な手法なんです。
インフラエンジニアを目指す皆さんも、開発者の方も、この「206」という数字を見かけたら、「お、今このシステムは効率的にデータをやり取りしているな！」と、裏側でパケットが賢く分割されている様子を想像してみてください。
一歩ずつ、こうして技術の裏側の「なぜ？」を紐解いていけば、ネットワークはもっと面白くなりますよ！
それでは、また次回の記事でお会いしましょう！
コメント