下载一个 2GB 的文件，下到 80% 网断了。重头来过？那太折磨人了。视频网站拖一下进度条，几秒就开始播，不用等整个视频下完。这些能力都靠 HTTP 的范围请求（Range Request）。

范围请求：只要资源的一部分

范围请求让客户端只请求资源的某一段。核心请求头是 Range：

范围请求的工作机制

  • Range: bytes=0-1023 —— 我要第 0 到 1023 字节（前 1KB）。
  • Range: bytes=1024- —— 我要第 1024 字节到结尾（从某处到末尾）。
  • Range: bytes=-512 —— 我要最后 512 字节。
  • Range: bytes=0-1023, 2048-3071 —— 我要两段（多段范围）。

服务器如果支持范围请求，返回 206 Partial Content，body 只有请求的那一段，并带 Content-Range: bytes 0-1023/2097152（说明这段在完整资源的什么位置，以及完整资源总大小）。

注意几个细节：

  • 单位是字节（bytes=），范围请求基于字节偏移，不是「行」或「块」。
  • 左闭右闭：0-1023 包含第 0 和第 1023 字节，共 1024 字节。
  • 206 不是 200：范围请求成功的状态码是 206 Partial Content，不是 200。客户端要靠 206 区分「这是部分内容」和「这是完整内容」。

断点续传：范围请求的典型应用

断点续传是范围请求最经典的应用。原理很简单：

断点续传的实现原理

  1. 客户端下载文件，记录已下载的字节数（比如下了 800MB，对应字节 0-838860800）。
  2. 网络中断，下载暂停。
  3. 恢复时，客户端发 Range: bytes=838860801-，告诉服务器「从第 838860801 字节开始接着给我」。
  4. 服务器返回剩余部分（206），客户端把这部分追加到已下载的部分后面。

这就是迅雷、浏览器下载「继续下载」的实现。关键在于客户端要记录「下到哪了」，恢复时用 Range 从断点继续。

但断点续传有个前提：资源在断点前后没变。如果服务器上的文件被改了，从旧字节偏移继续就会得到错乱的数据。所以客户端恢复时通常带上 If-Range（带上资源的 ETag 或修改时间），服务器验证资源没变才返回 206，变了就返回 200（整个新文件）——从头下，避免数据错乱。

多线程下载：把范围请求并发化

迅雷、IDM 这类下载工具的「多线程加速」，本质也是范围请求：

多线程下载：分段并发拉取

把一个文件分成 N 段（比如 4 段），每个线程用 Range 请求一段，4 个连接并发下载。下完后再按顺序拼接。这样做能更快，原因有两个：

  • 绕过单连接限速。有些服务器对单连接限速，开多连接能绕过这个限制。
  • 利用更多带宽。多连接并行能更充分地利用带宽。

代价是给服务器更多并发压力，有些服务器会限制单 IP 的并发连接数。

Accept-Ranges：声明支持范围请求

服务器怎么告诉客户端「我支持范围请求」？用 Accept-Ranges 响应头：

  • Accept-Ranges: bytes —— 我支持按字节做范围请求。
  • Accept-Ranges: none —— 我不支持范围请求。

客户端先发个普通请求（或 HEAD），看响应有没有 Accept-Ranges: bytes，有的话才能用 Range。如果服务器不支持，发了 Range 也白搭——服务器会忽略 Range 返回完整的 200。

静态文件服务器（Nginx、CDN）几乎都支持范围请求（默认开启）。但动态生成的内容（API 响应）通常不支持，因为没法定位「第 N 字节」——内容每次生成都可能不同。

取舍与边界

范围请求有几个值得注意的边界：

  • 多段响应的 Content-Type 变了。如果请求多段范围，服务器返回 206，但 Content-Type 变成 multipart/byteranges，body 是多段用 boundary 分隔。这比单段复杂，实战中多段用得少。
  • 范围必须合法。请求 Range: bytes=100-50（起点大于终点）服务器返回 416 Range Not Satisfiable。请求超出资源大小的范围也返回 416。
  • 范围请求和缓存。缓存范围响应有点复杂，因为同一个 URL 现在有多种「部分」表示。CDN 通常能缓存范围响应，但配置要注意。

收束：范围请求让大文件交互成为可能

范围请求让断点续传、多线程下载、视频流式播放成为可能。它的核心是 Range 请求 + 206 响应 + Content-Range 定位。下一篇讲 multipart 与表单提交——这是内容与编码阶段的最后一篇，把 body 的提交方式讲全。

关于十三Tech

我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。

我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。

如果你想继续跟完这套「图解 HTTP」，欢迎关注公众号 「十三Tech」。后续会按 URL 与报文、连接与传输、缓存与协商、安全与边界、HTTP/2 与 HTTP/3 这条线更新。

十三Tech公众号二维码