Linux大文件下载：从HTTP Range原理到wget/curl/aria2的断点续传实践

简介这份RAR压缩包聚焦Linux环境下断点续传与多线程下载的实现面向网络编程学习者、C开发者以及需要在大文件传输场景中优化下载效率的运维或后端人员。包内共4个文件以cc源码为主另有1个h头文件与1个txt说明文档整体仅3KB属于轻量级示例代码。其中CSocket.cc与CSocket.h构成基础的套接字封装负责网络连接的建立与管理http_main.cc则是主程序入口集中体现了HTTP断点续传请求与多线程分块下载的核心逻辑txt文件用于补充程序来源或使用说明。已有189人学习下载。压缩包虽然小巧但代码结构清晰完整覆盖初始化连接、获取文件信息、多线程分块、断点续传、错误处理等关键环节适合想理解底层网络编程实现细节的读者拆解与复用。1. 一张 download.rar 背后的硬需求Linux 大文件下载为什么非断点续传不可我见过最多的场景是这样的你在 Linux 服务器上敲下 wget开始拉一个 4GB 的 Linux 镜像等到第 2 个小时SSH 断了整个下载直接灰飞烟灭。再登录上去看到的还是一个 0 字节的空文件。标题里的 download.rar 可以理解为任何一个你想要的资源包但比压缩包本身更关键的是下载过程能不能扛住断线、能不能把单线程变成多线程并行。这篇笔记围绕 Linux 断点续传与多线程下载这条主线展开从 HTTP Range 原理讲起落到 wget、curl、aria2 三款工具的选型再给出一套可以直接抄作业的下载脚本和排查清单。适合经常在服务器上拉取镜像、数据集、固件包或备份文件的工程师。如果你也有过半夜爬起来重下文件的经历这篇文章应该能让你少熬几次夜。2. Linux 断点续传的原理与三款工具的选型wget、curl 与 aria2 谁能扛住掉线断点续传不是玄学它完全依赖 HTTP 协议里的一个约定Range。你告诉服务器“我只要文件从第 500 字节开始的部分”服务器认账就返回 206 Partial Content不认账就返回 200 把整个文件倒给你。搞清楚这一点你就明白为什么同一个下载命令有时候能续传有时候却从头再来。2.1 先搞懂断点续传在服务端是怎么认账的HTTP Range 与 206当你执行 wget -c 或 curl -C - 时客户端会带上一个形如Range: bytes500-的请求头表示“我已经有前面 500 字节把剩下的给我”。服务端如果支持就返回206 Partial Content同时用 Content-Range 告诉你可以继续的位置如果不支持则忽略 Range 头返回200 OK客户端只能重新下载。所以在做任何大文件下载之前我习惯先用 curl -I 看一下链接的响应头。这一步非常快能帮你避开很多后面要踩的坑# 查看下载链接是否支持断点续传的关键响应头 curl -I -L https://mirrors.example.com/linux.iso | grep -iE accept-ranges|content-length|HTTP/如果结果里有Accept-Ranges: bytes说明服务端支持分段请求断点续传和多线程下载都可以往下做。如果看到Accept-Ranges: none或者压根没有这个字段那后面无论你给 wget 加多少-c都只是在重新下载。注意-L要跟上很多镜像站点会先给你一个跳转地址最终落到对象存储或 CDN 节点只有最后一个响应头才真正代表文件服务的行为。这里也顺带说一个容易混淆的场景git clone 断点续传。git clone 并不是按 HTTP Range 来续传单个大文件的它走的是 git 协议或 SSH传输对象是“一坨小对象”。中途断掉后仓库目录里已经 fetch 下来的对象不会全部作废但也没有一个简单的git clone -c可以拿来继续。我一般会用 shallow clone 降低单次传输量或者干脆用 git fetch 分步拉取而不是指望下载器续传。这个和普通文件下载是两套思路不要混用。2.2 wget、curl、aria2 三条命令的真实差异与选型Linux 下最常见的下载工具就三个wget、curl、aria2c。它们各自都能断点续传但能力和适用场景差别很大。我把关键差异列成一张对照表工具断点续传参数多线程适用场景wget-c不支持单线程临时下载小文件、递归抓站curl-C -不支持单线程接口调试、脚本里精确控制请求头aria2c-c或--continue支持-x、-s大文件、批量下载、任务队列三条命令对应的最小续传写法是这样的# 三种工具各自最小的续传命令 wget -c -O linux.iso https://mirrors.example.com/linux.iso curl -C - -o linux.iso https://mirrors.example.com/linux.iso aria2c -c -x 8 -s 8 -o linux.iso https://mirrors.example.com/linux.isowget 的-c最直观但它的断点续传依赖服务端正确响应 Range。如果服务端返回 200wget 会直接覆盖原文件相当于前面白下了。curl 的-C -会自动从本地已存在文件的大小推断偏移量行为比 wget 更严谨但它仍然是单线程。aria2c 的-c配合-x 8 -s 8既能断点续传又能把文件拆成多段并行下载是做 Linux 大文件下载的第一选择。选型的结论很直接临时拉一个小包有人给你链接用 wget在 shell 脚本里需要处理下载并查看请求头用 curl凡是文件超过几百 MB或者你想彻底解决掉线重来问题直接装 aria2。这三条都是 Linux 常用命令但不要一杯水端到底不同工具解决的问题不一样。3. 多线程下载的落地让 aria2c 按你想要的并发数跑起来aria2c 的多线程原理不复杂它把同一个文件按字节偏移拆成多个段每段开一个连接去下载最后拼回一个完整文件。你看到的是 8 个连接同时在跑实际每个连接都在服务端的 Range 支持范围内工作。要做到这一点关键是选对参数别把它当成一把只会用最大连接数的锤子。3.1 aria2c 的最小可用命令多连接、分块与续传一起打开我第一次用 aria2c 时以为只要-x 16就能拉满速度结果发现连接是开了但服务端根本不给这么多分段进度也乱。后来才明白-x控制每个服务器的最大连接数-s控制文件拆分份数--min-split-size决定多小的文件不值得拆。一个完整的最小命令长这样# 用 8 个连接分 8 段下载每段至少 1M支持断点续传 aria2c \ --dir/data/download \ --outlinux.iso \ --max-connection-per-server8 \ --split8 \ --min-split-size1M \ --continuetrue \ https://mirrors.example.com/linux.iso--dir指定下载目录--out指定输出文件名。--max-connection-per-server8表示对同一台服务器最多开 8 个连接--split8表示把文件分成 8 段。这里的逻辑是如果文件只有 10MB--min-split-size1M会让它实际只拆成 10 段以内不会为了凑 8 个连接硬拆出一个 300KB 的碎片段。--continuetrue是打开断点续传的开关中断后再次执行相同命令aria2c 会从.aria2控制文件里读取进度继续。注意一个细节aria2c 下载时会生成一个带有.aria2后缀的同名控制文件这个文件保存了每一段已完成的位置。下载成功后它会自动消失。如果任务中断看到这个控制文件不要删它是你的后悔药删了就彻底失去续传依据。3.2 并发数不是越大越好线程数、分块大小与限速的平衡很多人在云服务器上开-x 16以为连接越多越好结果被 CDN 直接限流甚至触发安全策略返回 403。原因很现实服务器的带宽、CPU、磁盘 IO 都是资源单条 TCP 连接也不一定能占满你的下行带宽。我自己的经验是普通文件服务器用 4 到 8 个连接就足够慢速大文件可以到 12但超过 16 基本没有收益。分块大小也会影响稳定性。--min-split-size设置太小比如 64K会让 aria2c 为几 GB 的文件生成几十上百个段管理和合并的开销反而变大。常见的做法是 1M 到 5M。下面这个命令在并发之外加上了总速度限制适合多人共用的服务器避免下载占满出口带宽# 限制总下载速度最大 10M/s并输出日志 aria2c \ --dir/data/download \ -x 4 -s 8 -k 1M \ --max-download-limit10M \ --continuetrue \ --log/var/log/aria2.log \ https://mirrors.example.com/linux.iso这里-x 4是连接数-s 8是分段数分段数可以大于连接数多余的分段会排队。--max-download-limit10M控制的是整个任务的总速度不是你想象中每个连接 10M。--log参数在排查问题时非常有用网络抖动导致多次重连时日志里会留下明确的痕迹。并发参数没有固定公式但有一个可参考的起点文件小于 100MB-x 2足够1GB 左右-x 4 -s 410GB 以上-x 8 -s 8起步。下载中途进程被杀重新执行同一条命令只要.aria2控制文件还在它就能续上不需要手动指定偏移。3.3 一个完整的下载示例用 aria2c 拉取 Linux 镜像实际下载 Linux 镜像时镜像站通常提供了官方校验文件。我的习惯是让 aria2c 下载完镜像后立刻做一次 md5sum 校验避免拿到一个残缺的 ISO 还去安装系统。下面的命令组合了目录准备、多线程下载和校验# 建目录并下载 Ubuntu 服务器镜像 mkdir -p /data/download cd /data/download aria2c -x 8 -s 8 -k 1M -c \ https://mirrors.example.com/ubuntu/22.04/ubuntu-22.04-live-server-amd64.iso # 如果手动下载了官方 md5 文件校验整体性 md5sum -c ubuntu-22.04-live-server-amd64.iso.md5第一段命令先创建下载目录并进入这样 aria2c 默认把文件写到当前目录。-x 8 -s 8是为镜像这类大文件准备的参数即使中途断网重跑一次这条命令进度还会从断点继续。第二段命令的-c是--check的意思注意这里它不是指续传而是让 md5sum 读取 md5 文件里的逐条校验记录一一比对。如果你下载的不是镜像而是一个资源包比如标题里那种 download.rar下载完成后先不要急着解压先执行一次unrar t或者直接file download.rar确认文件类型。很多“下载完打不开”的问题其实是因为 CDN 返回了一个 404 页面文件名后缀是.rar但内容根本不是压缩包。4. 把 download.rar 场景变成脚本一个支持断点续传的多线程下载器命令背得再熟到了生产环境还是需要脚本。原因很简单下载任务往往不是一次性的失败要重试日志要留存退出码要判断。与其每次手敲一长串 aria2c 参数不如把常见的续传、并发、重试逻辑封装成一个 shell 脚本放到任何 Linux 服务器上都能用。4.1 封装脚本之前需要想清楚的三个约束写脚本之前先想想你真正需要它做什么。第一是任务中断后的恢复方式脚本如果中途被杀再跑一次必须能从上次的进度继续也就是说脚本本身不能主动清理.aria2控制文件。第二是日志的可读性你不能只输出到终端因为 SSH 断开后你再想看输出就没了必须同时写入日志文件。第三是退出码的语义aria2c 的退出码不全是 0 和 1不同退出码代表不同故障脚本要根据退出码决定是否重试。还有一个容易被忽略的约束不要自己写分段下载逻辑。网上很多方案用 wget 配合后台进程分别下载不同字节段最后 cat 合并这个思路可行但非常容易翻车——某个段失败后整个文件就废了你还得自己维护偏移量。aria2c 已经把分段和管理复杂度封装好了脚本里只需要调用它。4.2 download.sh 脚本支持续传、并发、重试与校验下面这个脚本是我在服务器上常用的模板参数很简单第一位是 URL第二位是输出文件名第三位是并发数。默认日志写到/var/log/downloader失败后重试 5 次每次间隔 5 秒。你可以直接保存为download.sh使用。#!/usr/bin/env bash # download.sh - 使用 aria2c 实现多线程断点续传下载 # 用法: ./download.sh url [output_name] [threads] set -uo pipefail URL$1 OUT${2:-$(basename $URL)} THREADS${3:-8} LOG_DIR${LOG_DIR:-/var/log/downloader} LOG_FILE${LOG_DIR}/${OUT}.log MAX_RETRY${MAX_RETRY:-5} command -v aria2c /dev/null 21 || { echo 缺少 aria2c请先安装apt install aria2 / yum install aria2 exit 1 } mkdir -p $LOG_DIR # 若存在旧的 .aria2 控制文件说明上次任务未完成保留它用于续传 retry0 while [ $retry -lt $MAX_RETRY ]; do echo [$(date %F %T)] 开始下载 ${URL}输出 ${OUT}线程 ${THREADS}第 $((retry1)) 次尝试 | tee -a $LOG_FILE aria2c \ --dir$(dirname ${OUT}) \ --out$(basename ${OUT}) \ --max-connection-per-server$THREADS \ --split$THREADS \ --min-split-size1M \ --continuetrue \ --log-levelnotice \ --log$LOG_FILE \ $URL exit_code$? if [ $exit_code -eq 0 ]; then echo [$(date %F %T)] 下载完成: ${OUT} | tee -a $LOG_FILE break else retry$((retry 1)) echo [$(date %F %T)] 下载中断退出码 ${exit_code}等待 5 秒后重试 | tee -a $LOG_FILE sleep 5 fi done if [ $retry -ge $MAX_RETRY ]; then echo 达到最大重试次数${MAX_RETRY}仍未完成。 echo 相同命令再执行一次即可续传.aria2 控制文件仍已保留。 exit 1 fi # 如果同时准备了 md5 值做完整性校验 if [ -n ${MD5SUM:-} ]; then echo ${MD5SUM} ${OUT} | md5sum -c - /dev/null 21 \ echo [$(date %F %T)] MD5 校验通过 \ || echo [$(date %F %T)] MD5 校验失败请勿使用该文件 fi脚本里最值得注意的细节是exit_code$?必须紧跟 aria2c 命令之后捕获否则 echo 命令会把$?覆盖掉重试逻辑就会拿错退出码。第二是set -uo pipefail-u能在未定义变量时立刻报错pipefail保证管线中任一环节失败都能被脚本感知。第三是--continuetrue必须保留很多失败的脚本一开始就默认它会续传实际上这个参数如果不显式打开aria2c 遇到同名文件会重新下载。4.3 为什么不用 wget 做多线程脚本里最常见的误用我在维护下载脚本时看到过一种误用用wget -c跑一个循环断线后重新执行 wget看起来像续传实际因为服务端不支持 Range每次都从 0 开始。这种脚本的问题在于日志里全是“重新下载”你根本察觉不到文件其实一直在重来。换个方式先用 curl -I 验证 Accept-Ranges再决定要不要走续传能省下大半天时间。另一个常见误用是把并发数写死。同一个脚本在公司内网下载一个 500MB 的安装包-x 8很合适但放到一个带宽只有 2M 的跳板机上8 个连接反而让路由器丢包率升高。脚本里把线程数作为第三位参数而不是硬编码是我现在坚持的习惯。脚本完成后后台运行和看日志这两条 Linux 常用命令也值得一起记住# 用 nohup 让下载脚本在 SSH 断开后继续跑 nohup ./download.sh https://mirrors.example.com/big.bin big.bin 8 download.log 21 # 实时跟踪日志 tail -f download.lognohup不会让脚本变成守护进程但它能避免终端关闭时向进程发送 SIGHUP配合就能在后台运行。tail -f是排查下载卡住时的第一选择如果日志长时间不变化再用ps -ef | grep aria2c看进程是否还活着。5. 断点续传与多线程下载的常见坑从“显示继续但重新下载”到“文件被改”再好的脚本也会遇到外部环境的刁难断点续传这块的坑基本都是服务端行为、控制文件状态、磁盘空间三者之一出了问题。下面五条是我踩过或者帮别人踩过的真实记录每一条都按现象、原因、解决三步写清楚。5.1 现象明明加了 -c进度却从 0 开始这是最多的投诉。你执行wget -c输出的第一行还写着“已经获取到 500M还有 100M”下一秒它就从 0 开始下载了。原因通常不是命令写错而是服务端忽略了 Range 请求直接返回 200。很多静态站、预览服务器并不会认真处理 Range 头尤其是一些基于旧框架的文件下载接口。解决方法是先确认响应头。我给自己定过一个规矩凡是需要断点续传的文件先跑一次curl -I -L url看到 Accept-Ranges 才用-c。如果是自己维护的下载服务检查反向代理有没有把 Range 头传递给后端比如 Nginx 的proxy_set_header Range $http_range;这是最容易漏的那一行。5.2 现象下载完成后文件 md5 值与官方发布不一致下载“成功”了但解压时提示压缩包损坏或者 md5sum 对不上。可能的原因有两个一是 CDN 缓存了不完整对象你拿到的是一个切片损坏后的副本二是 aria2c 并行下载时某个连接返回了错误页但状态码恰好是 206导致错误内容被写进了分段。解决方式是在脚本里强制加入完整性校验。如果文件下载到本地名为download.rar官方 md5 与文件同目录下直接用md5sum -c download.rar.md5。这个习惯不用每次手动执行写进 download.sh 的收尾部分即可。另外下载完成后先用file download.rar看一眼文件类型如果显示 HTML 或 text基本就是 CDN 拦截或者 404 兜底页。5.3 现象aria2 中断后再次运行不续传而是重新下你重新执行了同一条 aria2c 命令但它没有读.aria2控制文件反而在目录里生成了一个新文件。最常见的原因是下载目录里已经存在一个同名文件并且这个文件不是你上一次下载留下的或者它的修改时间比控制文件还新。aria2c 出于安全考虑不敢直接用控制文件去覆盖一个未知状态的文件。解决方法是先查看目录里download.rar和download.rar.aria2的 mtime如果控制文件有时间而目标文件被临时脚本清理过就要把.aria2控制文件和目标文件放在同一个目录下。还有一点--auto-file-renamingtrue是 aria2c 的默认值它会在同名文件存在时自动改名成download(1).rar让你误以为没有续传。续传任务建议显式加--auto-file-renamingfalse确保文件名不变。5.4 现象下载目录磁盘空间不足任务卡住多线程下载时空间消耗往往比你预期的多。每个分段都有自己的写入偏移aria2c 看起来是最终文件大小的占用但某些情况下临时文件会占用更多空间比如分段尚未合并时控制文件记录带来的额外开销。df -h显示还有 1GB 剩余但一个 800MB 的文件下载到最后一步时却报No space left on device。解决方式是为下载目录预留最终文件大小 10%~20% 的余量。大数据下载之前用du -sh和df -h检查。另外不要用/tmp作为下载目录很多发行版把/tmp挂载为 tmpfs重启后数据全没那你的.aria2控制文件也跟着消失断点续传自然无从谈起。服务器下载大文件我一般在/data/download这类持久化磁盘上做。5.5 现象文件大小正确但分段边界处有损坏这个坑比较隐蔽文件总字节数和服务端 Content-Length 一致但解压时偏偏在某个位置报错。原因是部分 CDN 节点对 Range 响应的边界处理不严谨多线程下载时两个分段交接的位置多了一段或少了一段而 aria2c 在合并时没有发现字节总数异常。解决方式是把分段数降下来重新下载或者直接用单线程命令测试那段区域。如果 CDN 对 Range 支持不完整多线程确实不适合这个资源这时宁可慢一点也要先保证文件正确。另外如果资源本身是 rar 压缩包下载后可以用rar t download.rar做一次测试解压它能直接告诉你哪个分卷受损这比 md5 更快定位问题。6. 进阶把断点续传下载放到任务队列里同时盯住下载完整性上面的脚本只解决“一个文件下载”的问题但实际工作中往往有一批 URL 要拉尤其是镜像同步、资源包分发这种重复任务。aria2c 自带的 session 机制比写一堆外部脚本更合适。你可以把多个 URL 放在一个 session 文件里aria2c 负责调度。它的两个参数--save-session和--input-file配合起来能做到进程重启后任务列表自动恢复。命令如下# 第一次下载时保存 session后续中断后可直接从 session 续传 aria2c --dir/data/download -x 8 -s 8 -c \ --save-session/data/aria2.session \ https://mirrors.example.com/a.iso \ https://mirrors.example.com/download.rar # 下次从 session 文件加载全部任务 aria2c --dir/data/download -x 8 -s 8 -c \ --input-file/data/aria2.sessionsession 文件里保存的不只是 URL还有每条 URL 对应的控制文件路径、下载临时状态。就算服务器重启只要 session 文件在--input-file会把未完成任务带回来。我还会给--save-session-interval60让 aria2c 每分钟自动把进度写回 session 文件断电丢状态的窗口就非常小了。完整性校验和 session 要保持同一条收尾逻辑。算完 md5 不急着庆祝先看 aria2c 的退出码和日志里的Download complete信息然后对 session 里每个任务做file类型抽查。如果发现某个文件是 HTML 错误页就要从 session 里剔除后重新拉。现在我每台下载服务器都保留一份 download.sh 模板和固定的 session 路径新任务到了就扔给这个模板跑。大文件下载不是拼谁的单线程快而是拼掉线之后恢复成本有多低。如果你准备长期处理 Linux 镜像、数据集或资源包这套断点续传加多线程的组合可以省去大量重复劳动。希望帮到你。本文还有配套的精品资源点击获取