HTTP Range Requests: How Video Seeking Works Over a CDN

A player seeking to minute 40 of a 4 GB MP4 sends one byte range request for roughly 1 MB. If your CDN caches whole objects only, that single seek pulls all 4 GB from origin: about 4,096x egress amplification for bytes nobody will watch. HTTP range requests, specified in RFC 9110, combined with slice-based partial-content caching, reduce that to a 1–2 MB origin fetch and a 206 Partial Content response measured in tens of milliseconds. The gap between those two behaviors is visible on your origin egress bill and in seek latency at p95.

How HTTP range requests actually move video bytes

The contract is small. The origin advertises Accept-Ranges: bytes. The client sends Range: bytes=2100000000-2101048575. A compliant server answers 206 Partial Content with Content-Range: bytes 2100000000-2101048575/4294967296 and a Content-Length equal to the range size, not the resource size. If the requested range is outside the representation, the answer is 416 Range Not Satisfiable with Content-Range: bytes asterisk/total.

For progressive MP4, the player first fetches the head of the file to read the moov atom, resolves the sample table, converts a timestamp into a byte offset, then issues a byte range request for that offset. Fragmented MP4 and CMAF shift the work: the init segment plus an index (sidx) map presentation time to byte ranges, and HLS byte-range playlists address sub-ranges of a single large media file through EXT-X-BYTERANGE. Same protocol mechanics, different indexing layer.

Resumable downloads use the same primitive with an added validator. The client sends If-Range with the strong ETag or Last-Modified it saw earlier. If the validator still matches, it gets 206 and continues; if the resource changed, it gets a full 200 and restarts. That fallback is correct and expensive, and it is where most production breakage hides.

What partial-content caching does to origin egress

Slicing is the edge-side answer. Instead of treating the object as one cache entry, the CDN normalizes each incoming range onto fixed-size aligned blocks, fetches only the missing blocks from origin with its own range requests, and assembles the response. Cache keys become object-plus-slice-index.

Assume a 4 GB VOD asset, a cold cache, and a single 1 MB seek. The table below models origin behavior under different slice granularities. Figures are arithmetic from those assumptions, not measurements.

The single most important conclusion: slice size trades wasted origin bytes per seek against origin request count, and for interactive video seeking, 1 MB sits close to the point where both stay tolerable.

The second-order effect is measurement. Slicing splits one client request into several cache lookups, so request hit ratio stops describing your economics. Byte hit ratio, and better still origin offload defined as one minus origin bytes divided by delivered bytes, is the number that maps to the invoice.

Where range request video setups break in production

Weak or unstable ETags are the top offender. If two origin nodes generate different ETags for the same object, or a framework emits a weak validator, If-Range comparisons fail and the edge falls back to full 200 responses. Slice caches then thrash, and origin egress climbs back toward the unsliced number without any alert firing.

Second: origins that ignore Range entirely. Packagers, transmuxers, and some application frameworks answer 200 with the whole body regardless of the header. The CDN cannot slice what the origin will not partial-serve, and the player waits for bytes it does not need.

Third: compression on the same path. Ranges apply to the selected representation, so a Vary on Accept-Encoding plus content-coding on a media route makes offsets ambiguous between clients. Do not compress already-compressed media; keep range-served routes free of dynamic encoding.

Fourth: multipart/byteranges. Multi-range responses are legal, poorly handled by intermediaries, and rarely requested by players. Collapsing multi-range requests into a single covering range or a 200 is the safer edge policy.

Trade-offs worth stating out loud

Small slices raise origin request rate, and connection and TLS overhead per slice matters more than the bytes at 256 KB granularity. Very large slices convert seek-heavy traffic into wasted egress. Slicing also delays first-byte on cold seeks slightly, because the edge must complete a full slice fetch before it can serve the requested sub-range unless it streams while writing.

Prefetching adjacent slices helps sequential playback and hurts on catalogs where users abandon after 30 seconds. If you enable it, cap it at one or two slices ahead and measure fetched-but-unserved bytes. Slice metadata also inflates cache index entries roughly by object size divided by slice size, which becomes real memory pressure on a multi-petabyte edge tier.

Verify this on your own stack

• Send a request with Range: bytes=0-1 to a media URL. Expect 206, Accept-Ranges: bytes, and a Content-Range whose total matches the object size.
• Repeat the same request twice and compare the cache status header. A second miss on an unchanged object means slice keys or validators are unstable.
• Compare byte hit ratio with request hit ratio for the last 7 days. A gap wider than 10 percentage points usually points at slice size or ETag drift.
• Log the Range header and the response status. A rising ratio of 200 to 206 on media routes is the earliest signal of origin regression.

Slice granularity, prefetch depth, and shield behavior should be property-level settings rather than a global default, and BlazingCDN exposes that alongside NVMe SSD edge storage, which keeps random-offset slice reads inexpensive during seek storms. If you are auditing options, its per-property CDN cache and range request configuration is a reasonable reference point for what to demand from any vendor.

FAQ: HTTP range requests and video seeking

What is a 206 Partial Content response?

A 206 Partial Content response is the server's answer to a valid Range header, returning only the requested byte interval. It must include a Content-Range header naming the first byte, last byte, and total representation length, and its Content-Length equals the range size, not the file size. Clients treat a 200 in reply to a Range header as a full-body fallback.

Why does video seeking fail when the origin does not support byte range requests?

Because the player cannot ask for a mid-file offset and must download from byte zero to reach the target timestamp. On a 4 GB asset, a seek to the midpoint means transferring roughly 2 GB before playback resumes. Symptoms are long seek stalls, high abandonment on long-form content, and origin egress that scales with watch attempts rather than watched bytes.

What slice size should a CDN use for range request video delivery?

For general video on demand, 1 MB is the common default in 2026 configurations, with 2 MB reasonable for high-bitrate ladders. Smaller slices cut wasted origin bytes per seek but multiply origin request count; 8 MB and above suits sequential large-file downloads such as game patches. Validate the choice against measured byte hit ratio, not request hit ratio.

Run this measurement this week

Pick your ten largest media objects and pull a day of edge logs for them. Compute delivered bytes, origin bytes, and the ratio of 206 to 200 responses per object. Then change slice size on one test property, wait for the cache to warm, and recompute. If origin offload moves less than two percentage points, your bottleneck is validator stability or an origin that ignores Range, not slice tuning. Post the before-and-after numbers to your platform channel; that single table usually ends the argument about whether partial-content caching is worth configuring properly.