平时在下载大文件的时候，比如更新系统镜像或者看高清电影，网络突然断了，要是不能接着上次的地方继续下，那就太折磨人了。好在现在的下载工具基本都支持“断点续传”，其实这背后靠的就是HTTP协议本身的能力。
HTTP本身不直接“续传”，但提供了支持机制
严格来说，HTTP请求本身不会自动断点续传，但它通过Range请求头和服务器的配合，实现了这个功能。当客户端（比如浏览器或下载器）发现下载中断，它能记住已经拿到的数据位置，下次请求时告诉服务器：“我从第10MB开始拿，前面的不要了”。
怎么实现的？看个实际例子
假设你要下载一个200MB的安装包，已经成功下载了前80MB，突然断网。恢复后，下载工具不会重新开始，而是发送这样一个请求：
GET /large-file.zip HTTP/1.1\nHost: example.com\nRange: bytes=80000000-服务器如果支持断点续传，就会返回状态码206 Partial Content，并且只发送从第80,000,000字节开始的数据。这样就接上了，不用重来。
服务器得配合才行
光客户端支持没用，服务器也得能处理Range请求。常见的Web服务器如Nginx、Apache默认都支持，但有些老旧系统或自定义服务可能没开启。可以通过响应头判断是否支持：
HTTP/1.1 206 Partial Content\nContent-Range: bytes 80000000-199999999/200000000\nAccept-Ranges: bytes看到Accept-Ranges: bytes，说明这个资源支持按字节范围请求。如果是none，那就不支持断点续传。
实际运维中要注意啥
在服务器维护过程中，如果你负责部署静态资源服务，记得确认Range请求是开启的。比如Nginx里有个配置叫max_ranges，设为0就等于关掉了断点续传，用户下载大文件一旦中断就得重来，体验很差。
另外，CDN节点有时候也会对Range行为做缓存策略调整，某些边缘节点可能不完整支持，导致部分用户无法续传。这时候需要检查CDN设置，确保206响应能正确穿透。
所以别以为断点续传是客户端的“魔法”，它是HTTP协议、服务器配置和客户端逻辑共同协作的结果。运维人员稍微留意一下相关头信息和配置，就能避免很多用户抱怨“为啥总要重新下载”。