下载一个2GB的软件安装包，刚下到80%手机没电自动关机了——别慌，下次连上Wi-Fi点继续下载，进度直接从1.6GB开始。这种‘掉线不重来’的体验，靠的就是断点续传。
它不是魔法，是HTTP协议里的一个小技巧
传统HTTP下载默认从头开始，服务器一收到GET请求，就把整个文件从第1字节吐出来。而断点续传的关键，在于客户端告诉服务器：‘我已经有前1.6GB了，你从第1610612736字节开始给我剩下的就行。’这靠的是HTTP头部的 Range 字段。
比如浏览器发这样的请求：
GET /setup.exe HTTP/1.1\r\nHost: example.com\r\nRange: bytes=1610612736-\r\nAccept: */*\r\n服务器如果支持断点（返回状态码206 Partial Content），就会只返回从指定位置到结尾的数据，同时在响应头里带上：Content-Range: bytes 1610612736-2147483647/2147483648。
客户端得自己记账
光靠服务器不够，客户端必须本地存好已下载的字节范围。比如用一个临时文件 setup.exe.part，再配一个同名的元数据文件 setup.exe.part.meta，里面记着：{"downloaded": 1610612736, "total": 2147483648, "url": "https://example.com/setup.exe"}。重启后先读这个文件，再拼出带Range的请求。
多线程下载怎么续？
有些下载工具会把一个大文件切成几块，同时开3个连接分别下前1/3、中间1/3、后1/3。这时候每一块都要独立记录起始偏移和当前进度。比如第一块负责0–715827882字节，它中断时只记自己下了多少，不影响另外两块。最后合并时按偏移顺序把所有块拼成完整文件即可。
FTP和BT走的是另一套路
FTP协议原生支持 REST 命令，客户端直接发 REST 1610612736，再发 RETR setup.exe，服务器就从那个位置继续传。而BT这类P2P下载，本质就是下一个个小块（piece），每个块有独立哈希校验，哪块没下完就单独重下，天然支持‘断点’，只是我们平时不这么叫它罢了。