大刀阔斧，彻底重构 Gopeed HTTP 下载实现

前言

在 GitHub 上经常收到用户反馈类似问题：

下载老是失败，要手动重试好几次
下载卡在 99% 不动了
等等

这其实也算是项目初期埋下的技术债了，这次痛定思痛，决定对下载引擎进行一次大刀阔斧的重构。

此次重构（PR #1229）改动了 30 个文件、3000 多行代码，希望从根本上解决这些痛点。

背景

Gopeed 在设计之初就规划了多协议支持能力，为此我将下载流程抽象为两个独立阶段：

解析阶段：获取文件元信息（大小、名称、是否支持断点续传等）
下载阶段：基于文件信息执行实际的数据传输

这种设计在理论上看似合理，但在实际应用中逐渐暴露出一些问题：

问题一：解析阶段造成资源浪费

经常使用浏览器下载的用户应该会发现：当你还在选择保存路径时，下载实际上已经在后台进行了。而 Gopeed 的实现却是：

建立连接 → 获取文件信息 → 立即关闭连接 → 用户确认 → 重新建立连接 → 开始下载

这意味着解析阶段建立的连接完全被浪费，没有用于实际数据传输。对于小文件，这种设计尤其低效——等用户确认时，文件本可以早已下载完成。

问题二：固定分片导致“卡在 99%”

当前实现采用固定分片算法：将文件平均分成 N 份，每个连接负责一份。这种设计存在致命缺陷：

如果某个分片对应的服务器节点响应慢，其他连接即使完成也只能空闲等待
形成“一方有难，八方围观”的局面
用户体验表现为：前 99% 飞快，最后 1% 可能卡很久

问题三：缺乏智能重试机制

现有实现对网络错误的处理过于简单粗暴：

网络抖动、服务器临时繁忙等可恢复错误直接导致下载失败
用户只能手动点击“继续下载”，体验糟糕
没有区分可重试和不可重试的错误类型

问题四：第三方库深度魔改带来的维护困境

为了适配“解析-下载”两阶段模型，对 anacrolix/torrent 库进行了大量侵入式修改：

无法及时跟进上游更新，错失性能优化和 Bug 修复
维护成本随时间推移呈指数级增长
技术债务积累严重

重构方案：三大核心改进

针对上述问题，此次重构引入了三个关键技术改进：

改进一：连接复用机制

核心思路：

既然已经建立了连接，就不要浪费了，让它直接用于下载。

实现方案：

旧版本流程：点击下载 → 建立连接 → 获取文件信息 → 关闭连接 → 用户确认 → 重新建立连接 → 开始下载
新版本流程：点击下载 → 建立连接 → 获取文件信息 → 保持连接 → 用户确认 → 直接开始下载

技术细节：

第一个连接在获取文件元信息后不再关闭，而是立即开始预下载（写入临时文件）。这样做带来两个好处：

零延迟启动：用户点击确认后，进度条立即开始移动
资源高效利用：用户确认前就已完成大部分下载

改进二：更智能调度算法

核心思路：

下载连接之间应该互相协作，而不是各自为战。

问题根源分析：

旧版本采用固定分片算法：

文件大小：1GB，连接数：16
每个连接负责：1GB ÷ 16 = 64MB

连接1: [0MB - 64MB]
连接2: [64MB - 128MB]
...
连接16: [960MB - 1024MB]

如果有一个连接下载速度很慢，其他 15 个连接即使完成也无法帮忙。

新版本解决方案：

引入动态分片 + 工作窃取机制：

动态分片：不再预先固定每个连接的下载范围
工作窃取：空闲连接主动“窃取”未完成连接的剩余任务

算法示意：

初始状态：
连接1-15: 已完成
连接16: 还剩 10MB [990MB - 1000MB]

触发工作窃取：
连接1: 窃取 [990MB - 991MB]
连接2: 窃取 [991MB - 992MB]
...
连接15: 窃取 [1004MB - 1005MB]
连接16: 继续下载 [1005MB - 1010MB]

结果：16 个连接同时工作，快速完成最后 10MB

通过这个优化极大的提升了最后阶段的下载速度，避免“卡在 99%”太久的问题。

改进三：智能重试 + 渐进式连接扩展

3.1 智能重试机制

错误分类处理：

根据错误类型采取不同的策略：对 429 Too Many Requests、503 Service Unavailable 这类临时性错误，采用指数退避并自动重试；而对 404 Not Found、403 Forbidden 等确定性错误，则直接失败并给出清晰提示。

指数退避算法：

在每次重试之间引入指数退避等待时间，避免短时间内频繁请求服务器：

第1次重试：等待 1 秒
第2次重试：等待 2 秒
第3次重试：等待 4 秒
第4次重试：等待 8 秒
第5次重试：等待 16 秒

快速失败重试：

“指数退避”只能管住重试的节奏，但如果有一条连接比较慢，比如卡在TCP连接或者TLS握手阶段，也会把整体下载速度拖下来。

所以新版本做了一个更“聪明”的处理：只要下载已经跑起来（已经有连接成功开始传数据），后续连接就会进入快速失败重试阶段——不再死等固定的 15 秒超时；而是根据实际网络状况，动态调整超时时间，以便更快地放弃无效连接，重新发起新下载请求。

3.2 渐进式连接扩展

问题：

一次性同时开启大量连接容易触发服务器限流，而且对于小文件来说，很多连接可能根本用不上，浪费资源。

解决方案：

借鉴 TCP 慢启动思想，逐步增加连接数：

1 个连接
2 个连接  (x2)
4 个连接  (x2)
8 个连接  (x2)
16 个连接 (达到上限)

好处：

对服务器更友好，降低被限流/封禁风险
下载快的时候只需更少的连接即可完成

技术债务的清理

除了上述三大核心改进，此次重构还顺带解决了问题四：

Torrent 库：不再需要魔改

旧版本的困境：

为了适配“解析-下载”两阶段模型，对 anacrolix/torrent 进行了大量魔改：

修改了 200+ 行核心代码
每次同步上游库，都可能要重新适配

重构之后：

在解析阶段就直接指定下载目录，这样就可以避免魔改，直接使用其原生 torrent 的“指定下载目录”能力。

跨平台：一套代码，支持 6 大平台
多协议：HTTP(S)、BitTorrent、Magnet
高性能：Go 语言原生并发，充分利用多核
易扩展：插件系统，支持自定义协议和功能

感谢一直以来的支持！有任何问题或建议，欢迎留下评论或在 GitHub 提 Issue。

# 大刀阔斧，彻底重构 Gopeed HTTP 下载实现

前言

背景