简介：这份资源面向Linux网络编程学习者与需要实现大文件传输的开发者，聚焦断点续传与多线程下载两项核心技术，帮助理解如何在网络不稳定场景下提升下载效率与用户体验。包内共4个文件，以2个cc源文件、1个h头文件和1个txt说明为主，压缩包约3KB，体量轻巧但结构完整：套接字类封装负责网络连接管理，HTTP主程序承载断点续传与多线程下载逻辑，头文件定义接口，文本文件则提供来源与使用说明。已有190人学习下载，适合作为网络编程课程设计或练手项目的参考。读者可从中获取HTTP HEAD获取文件信息、分块下载、线程同步与合并、进度保存与恢复、错误处理等关键实现思路，并对照源码理解套接字通信与并发控制的落地方式，为自行实现高效下载工具提供可复用的代码骨架与排错参考。
1. 从 download.rar 说起：Linux 断点续传与多线程下载到底解决什么问题
你大概率遇到过这种场景：从一台海外镜像站拉一个 8GB 的 Linux 发行版 ISO，宿舍或办公室的网每隔十几分钟抖一次，wget 跑到 60% 断了，重来一遍又从 0% 开始。或者你在运维一台只有 1Mbps 出口的云主机，要从对象存储同步一个 20GB 的数据库备份，单连接跑满带宽也要跑一整天。download.rar这个标题背后，其实是一类非常具体的工程需求：在 Linux 上把「大文件下载」这件事做得可中断、可恢复、可并行。断点续传解决的是「断了不用从头来」，多线程下载解决的是「单连接跑不满带宽」。两者组合起来，才是生产环境里真正能用的下载方案。这篇笔记面向的是需要在 Linux 上稳定拉大文件的运维、后端和嵌入式开发者，从 HTTP Range 协议讲到 aria2、axel、wget 的实际配置，再到自己写一个可控的 Python 多线程下载器，把参数、坑和验证方法都摊开讲。
2. 断点续传的底层依据：HTTP Range 与文件分片怎么对上
2.1 断点续传不是「记住进度」那么简单
很多人对断点续传的理解停留在「下载工具记了个进度条」。实际上，断点续传能成立的前提是服务端支持HTTP Range 请求。客户端在请求头里带上Range: bytes=1024000-，意思是「从第 1024000 字节开始给我后面的内容」，服务端如果支持，会返回206 Partial Content而不是200 OK，并在响应头里给出Content-Range: bytes 1024000-10485759/10485760。客户端拿到这段数据后，用追加模式写进本地文件，就完成了「续」。
这里有个容易被忽略的点：断点续传的「断点」必须和本地文件的实际大小严格对齐。如果你本地文件已经有 1024000 字节，但请求时写的是Range: bytes=1000000-，那这 24000 字节就会重复写入，文件直接损坏。所以正确的做法是每次续传前先stat本地文件拿到真实大小，再拿这个值去拼 Range 头。这也是为什么很多下载工具在续传前会做一次 HEAD 请求，确认远端文件的总大小和Accept-Ranges字段。
判断服务端是否支持断点续传，最直接的方式是发一个 HEAD 请求看响应头：
curl -I -H "Range: bytes=0-1" https://example.com/ubuntu-24.04.iso如果返回里出现Accept-Ranges: bytes和206，说明支持；如果只有200且没有Accept-Ranges，那这个源就不支持断点续传，任何工具都救不了，只能换源。这是排查「为什么我的下载器续传失败」的第一步，别急着怀疑工具。
2.2 多线程下载的本质是把一个文件切成多个 Range
多线程下载并不是「开多个连接下载同一个文件」这么模糊。它的准确做法是：先通过 HEAD 拿到文件总大小total，然后按线程数N把[0, total)切成 N 段，每个线程负责一段，各自发Range: bytes=start-end请求，最后把 N 个分片按顺序合并。比如 100MB 文件、4 线程，每段 25MB，线程 0 请求bytes=0-26214399，线程 1 请求bytes=26214400-52428799，以此类推。
这里的关键参数是分片大小和线程数。分片太小，请求头开销占比高，而且服务端可能限流；分片太大，单线程跑太久，失去并行意义。经验值是单分片不小于 1MB，线程数控制在 4 到 16 之间。超过 16 线程，大多数服务端会触发并发连接限制，反而变慢甚至被封 IP。另外要注意，多线程下载和断点续传是正交的两件事：多线程解决速度，断点续传解决可靠性。一个成熟方案应该同时支持——每个分片自己记录已下载的偏移量，中断后从各自断点继续，而不是整个文件重来。
2.3 用 aria2 跑通第一个多线程断点续传任务
aria2 是 Linux 上最省心的选择，一条命令同时搞定多线程和断点续传：
aria2c \ -x 8 \ # 单服务器最大连接数，即线程数 -s 8 \ # 分片数，通常和 -x 保持一致 -k 1M \ # 每个分片最小 1MB -c \ # 开启断点续传 --file-allocation=none \ # 不预分配，避免大文件卡顿 -d /data/downloads \ # 下载目录 -o ubuntu.iso \ # 保存文件名 "https://mirrors.example.com/ubuntu-24.04.iso"-x和-s是最常调的两个参数。-x控制对同一服务器的并发连接数，-s控制文件被切成几片。两者设成一样最直观。-k是分片大小，默认 20M，对小文件偏大，改成 1M 更灵活。-c是续传开关，aria2 会在下载目录生成一个.aria2控制文件，记录每个分片的进度，下次执行同样的命令会自动读取它继续。注意：不要手动删除.aria2文件，删了就等于放弃断点，只能从头来。如果下载完成，aria2 会自动清理这个控制文件。
--file-allocation=none这个参数值得单独说。默认情况下 aria2 会预分配磁盘空间（falloc 或 trunc），对 20GB 的文件在某些文件系统上会卡住几十秒甚至报错。设成none就不预分配，边下边写。代价是磁盘碎片可能多一点，但对下载场景完全可接受。
3. 自己写一个可控的多线程断点续传下载器
3.1 为什么还要自己写
aria2 和 axel 已经很好用了，但有些场景你必须自己控制：比如要在下载过程中做鉴权刷新、要把分片写到不同的存储、要对接自己的任务调度系统、要在内网环境里去掉外部依赖。这时候一个 200 行左右的 Python 下载器比调参更靠谱。下面这个实现覆盖了 HEAD 探测、分片切分、多线程 Range 请求、断点记录和合并，核心逻辑都在注释里。
3.2 核心代码：分片、续传与合并
import os import threading import requests class MultiThreadDownloader: def __init__(self, url, filepath, threads=8, chunk_size=1024*1024): self.url = url self.filepath = filepath self.threads = threads self.chunk_size = chunk_size self.total_size = 0 self.lock = threading.Lock() def probe(self): # HEAD 探测总大小和是否支持 Range resp = requests.head(self.url, allow_redirects=True, timeout=10) self.total_size = int(resp.headers.get("Content-Length", 0)) accept_ranges = resp.headers.get("Accept-Ranges", "") if accept_ranges != "bytes": raise RuntimeError("服务端不支持 Range，无法断点续传") return self.total_size def download_part(self, index, start, end): part_file = f"{self.filepath}.part{index}" # 读取已有分片大小，实现分片级断点续传 existing = os.path.getsize(part_file) if os.path.exists(part_file) else 0 if existing >= (end - start + 1): return # 该分片已完成 headers = {"Range": f"bytes={start + existing}-{end}"} mode = "ab" if existing else "wb" with requests.get(self.url, headers=headers, stream=True, timeout=30) as r: r.raise_for_status() with open(part_file, mode) as f: for chunk in r.iter_content(chunk_size=64*1024): if chunk: f.write(chunk) def run(self): self.probe() part_size = self.total_size // self.threads ranges = [] for i in range(self.threads): start = i * part_size end = self.total_size - 1 if i == self.threads - 1 else (start + part_size - 1) ranges.append((i, start, end)) threads = [] for i, start, end in ranges: t = threading.Thread(target=self.download_part, args=(i, start, end)) t.start() threads.append(t) for t in threads: t.join() self.merge() def merge(self): with open(self.filepath, "wb") as out: for i in range(self.threads): part_file = f"{self.filepath}.part{i}" with open(part_file, "rb") as pf: while True: buf = pf.read(1024*1024) if not buf: break out.write(buf) os.remove(part_file) if __name__ == "__main__": d = MultiThreadDownloader( url="https://mirrors.example.com/ubuntu-24.04.iso", filepath="/data/downloads/ubuntu.iso", threads=8 ) d.run()逻辑上分四步：probe用 HEAD 拿总大小并校验Accept-Ranges；run按线程数切分区间；download_part每个线程独立请求自己的 Range，并且先检查本地分片文件已有多少字节，从已有偏移继续，这就是分片级断点续传；merge按序号顺序拼接分片并删除临时文件。参数上，threads建议 4 到 16，chunk_size是写入缓冲区大小，64KB 到 1MB 都行，太小会增加系统调用次数，太大占内存。timeout=30是连接和读取超时，内网可以调小，公网建议保留。
3.3 断点记录该存哪里
上面的实现把断点信息隐含在.partN文件的大小里，简单可靠，但有个前提：分片区间在每次运行时必须完全一致。如果第二次运行时threads从 8 改成 4，分片边界就变了，.part文件对不上，续传会出错。生产环境更稳妥的做法是额外写一个 JSON 元数据文件，记录total_size、threads、每个分片的start/end/downloaded，续传前先读元数据校验一致性。如果发现参数变了，要么按旧参数继续，要么提示用户清理重下。这个元数据文件就是你的「后悔药」，别省这一步。
4. 避坑与排查：断点续传和多线程下载最容易翻车的地方
4.1 续传后文件校验失败，md5 对不上
现象：下载完成，但md5sum和官方值不一致，文件打不开或解压报错。原因：最常见的是分片重叠或缺失。比如某个线程请求的 Range 起点算错，或者服务端返回的Content-Range和请求的不一致但客户端没校验，导致某段数据写了两遍或漏了一段。解决：在download_part里校验响应头Content-Range的起点是否等于请求起点，不等就抛异常重试。合并完成后，如果源站提供校验值，务必跑一次md5sum或sha256sum对比。别嫌麻烦，大文件下载最怕的就是「看起来完成了但内容是坏的」。
4.2 线程数拉满反而更慢，甚至被限流
现象：把-x设成 32 甚至 64，速度不升反降，或者跑一会儿全部连接超时。原因：服务端或中间网关对单 IP 的并发连接数有限制，超过阈值会触发限流甚至临时封禁。另外线程太多会导致磁盘随机写入加剧，机械盘上尤其明显。解决：线程数从 4 开始试，逐步加到 8、16，观察速度曲线。大多数场景 8 线程已经能跑满百兆带宽。如果服务端明确限制并发，就老实降到 2 到 4。记住，多线程下载的收益来自「单连接跑不满带宽」，如果单连接已经跑满，加线程没有任何意义。
4.3 磁盘空间不足导致续传文件损坏
现象：下载到一半报No space left on device，清理空间后重新运行，续传失败或文件损坏。原因：磁盘写满时，分片文件可能只写了一半，但文件系统记录的 size 和实际有效数据不一致。更糟的是，某些文件系统在空间不足时会截断写入。解决：下载前用df -h确认目标分区剩余空间大于文件总大小，最好留 10% 余量。如果已经写满，不要直接续传，先检查各.part文件大小是否合理，必要时删掉最后那个可能损坏的分片重下。aria2 的--file-allocation=falloc能在开始时就占住空间，避免下到一半才发现不够，但会牺牲启动速度，按需选择。
4.4 重定向后 Range 请求失效
现象：URL 经过 301/302 跳转后，续传请求返回200而不是206，或者返回的内容不是从指定偏移开始。原因：部分服务端在重定向后不保留 Range 语义，或者跳转到了不支持 Range 的 CDN 节点。解决：用curl -I -L跟踪完整跳转链，拿到最终 URL 后直接对最终地址发 Range 请求。代码里requests.head(allow_redirects=True)拿到的是最终响应头，但后续 GET 如果还用原始 URL，可能每次跳转行为不一致。稳妥做法是探测阶段就解析出最终 URL，后续所有请求都用它。
4.5 断点文件被误删或跨机器不通用
现象：换了台机器继续下载，发现断点信息没了，只能从头来。原因：断点信息存在本地.aria2或.part文件里，没有随文件一起迁移。解决：如果要跨机器续传，把控制文件和数据文件一起拷贝，并确保目标路径一致。自己写的下载器可以把元数据存成 JSON 放在文件同目录，迁移时一起带走。另外注意，不同工具的控制文件格式不通用，aria2 的.aria2不能被 axel 识别，别混用。
5. 进阶技巧：把下载器接进自动化流水线并验证完整性
5.1 用校验和与分段验证兜底
下载完成后只跑一次全文件 md5 是基本操作，但对超大文件，全量校验本身也要几分钟。更高效的做法是分段校验：如果源站提供分片校验值（有些镜像站会提供.sha256分片清单），可以在每个分片下载完就校验，发现问题立即重下该分片，而不是等整个文件合并后才发现。自己写下载器时，可以在download_part结束后对该分片算一次 sha256，和预期值比对。没有分片校验值就退而求其次，合并后全量校验。
5.2 把下载任务做成可重入的脚本
生产环境里，下载往往不是手动执行，而是由定时任务或 CI 触发。这时候脚本必须可重入：重复执行不会破坏已有进度，也不会重复下载已完成的部分。下面这个 bash 封装是一个我常用的模板：
#!/bin/bash set -euo pipefail URL="$1" OUT="$2" THREADS="${3:-8}" # 已存在且校验通过则直接退出，实现幂等 if [ -f "$OUT" ]; then echo "文件已存在，跳过下载" exit 0 fi aria2c -x "$THREADS" -s "$THREADS" -k 1M -c \ --file-allocation=none \ --max-tries=5 \ --retry-wait=10 \ -d "$(dirname "$OUT")" \ -o "$(basename "$OUT")" \ "$URL" # 下载后校验，失败则删除文件让下次重来 if ! md5sum -c "${OUT}.md5" 2>/dev/null; then echo "校验失败，清理文件" rm -f "$OUT" exit 1 fi关键点是--max-tries=5 --retry-wait=10，让 aria2 在遇到临时网络错误时自动重试，而不是直接失败退出。set -euo pipefail保证任何一步出错脚本就停，不会带着坏文件继续往下走。校验失败时删除文件，下次执行会重新下载，避免坏文件被当成「已完成」跳过。
5.3 监控下载进度和速度的实用命令
aria2 默认输出比较啰嗦，可以用--summary-interval=10控制摘要输出频率，或者加--console-log-level=warn只看警告。如果想在脚本里拿到进度，可以解析 aria2 的--show-console-readout输出，或者干脆用watch -n 5 'ls -l /data/downloads/*.part*'看分片文件增长。对于自己写的下载器，建议每个分片线程定期打印已下载字节数，方便判断是否卡死。一个简单的判断标准：如果 30 秒内所有分片大小都没变化，大概率是连接挂了，需要超时重连机制。
我自己的习惯是，任何超过 1GB 的下载任务，都必须带断点续传和校验，且脚本要能重复执行。早年吃过一次亏：一个 15GB 的备份文件下载完没校验，结果解压时报错，重新下载又花了 6 小时。从那以后，md5sum -c成了我所有下载脚本的标配。希望这些经验能帮到你，少走点弯路。
本文还有配套的精品资源，点击获取
