恢复中断的传输：永远不必从零开始

可恢复传输将文件切分为若干分块，并追踪哪些分块已被服务器成功接收；连接中断时，客户端从下一个未发送的分块继续，而不是从字节零重新开始。这一领域的 Web 标准是 tus.io（开放的可恢复上传协议），SwissTransfer、HexaTransfer、Vimeo、Cloudinary 以及许多现代传输服务均已实现该协议。下载端则由 HTTP Range 请求（RFC 7233）支持，浏览器和 curl、aria2 等工具可据此恢复中断的下载。若没有断点续传能力，一个 9.8 GB 的上传在传至 9.5 GB 时中断，代价是全部丢失——有了断点续传，最多只损失约 50 MB。

不支持断点续传的上传有何代价

传统文件上传将整个文件作为一个 HTTP POST 请求发送。任何中断——Wi-Fi 断开、VPN 超时、笔记本休眠、ISP 网络抖动——都会关闭 TCP 连接，服务器丢弃收到的所有部分数据，客户端从零字节重新开始。

对于 50 Mbps 连接上 5 GB 的上传，这意味着 13 分钟的工作付之东流。对于 50 GB 的上传，则超过两小时。非断点续传在移动网络上的失败率极高——4G 连接上进行 30 分钟的上传，第一次成功的概率非常低。

可恢复协议的工作原理

现代可恢复上传的基本流程如下：

创建： 客户端向服务器发送 POST 请求，携带文件总大小和元数据。服务器返回该次上传专属的 URL 并预留存储空间。
分块： 客户端将文件切分为若干分块（通常每块 5—64 MB）。
上传： 客户端将每个分块作为 PATCH 请求发送，并在 Content-Range 或 Upload-Offset 头中指明该分块的位置。
确认： 服务器将分块写入存储并确认新的偏移量。
恢复： 连接中断后，客户端向上传 URL 发送 HEAD 请求。服务器以当前偏移量（已收到的字节数）响应，客户端从该位置继续。
完成： 最后一个分块确认后，上传完成。

该模型由 tus.io 规范定义（1.0.0 版本已广泛部署）。其他变体包括 S3 Multipart Upload（用于直接 S3 上传）和 Google Cloud Storage Resumable Uploads。

tus.io：开放标准

tus（"transloadit upload server"）是由 Transloadit 维护的免费开放协议，规范发布于 tus.io，已被以下各方实现：

客户端库： tus-js-client（浏览器 + Node.js）、TUSKit（iOS）、tus-android-client、tus-java-client
服务端实现： tusd（Go 语言参考服务端）、tus-node-server 及多种框架集成
商业服务： SwissTransfer、HexaTransfer、Vimeo、Cloudinary、Transloadit、Uppy 的配套服务端

该协议刻意保持精简：四个 HTTP 动词（POST、HEAD、PATCH、OPTIONS），少量头字段（Upload-Offset、Upload-Length、Tus-Resumable）。这使实现简单、互通性强。

分块大小的选择

分块大小在恢复粒度与 HTTP 开销之间取得平衡。

| 分块大小 | 失败时最多重传量 | 请求开销 | |---|---|---| | 1 MB | ≤ 1 MB | 高（请求数多） | | 5 MB | ≤ 5 MB | 中等 | | 16 MB | ≤ 16 MB | 低 | | 64 MB | ≤ 64 MB | 极低 | | 256 MB | ≤ 256 MB | 几乎无开销，但失败代价大 |

稳定连接上，32—64 MB 分块能最大化吞吐量。移动网络或不稳定 Wi-Fi 上，2—5 MB 分块恢复更快。服务通常默认 5—10 MB 作为折中方案。

哪些因素会中断传输

了解故障模式有助于评估服务的断点续传实现是否健壮：

Wi-Fi 断开： 切换网络、信号丢失、路由器重启——极为常见
笔记本休眠： 在 macOS/Windows 上合上盖子，系统暂停网络；唤醒后连接通常需要重新建立
标签页挂起： 现代浏览器会挂起后台标签页以节省内存，处于挂起状态的标签页中的上传可能停滞
ISP/骨干网问题： 短暂路由变更、需要重新进行 TLS 握手
VPN 重连： VPN 客户端会定期重新协商，TCP 连接因此中断
服务端重启： 传输服务部署新版本时，进行中的请求会失败
企业防火墙干预： 正在检测流量的企业防火墙有时会切断长时间运行的连接

健壮的断点续传实现对以上所有场景采用相同机制：重新连接，发送 HEAD 请求查询偏移量，从该处继续。

下载端的断点续传

HTTP Range 请求（RFC 7233）驱动可恢复下载。在响应头中声明 Accept-Ranges: bytes 的服务器支持范围请求。客户端可发送 Range: bytes=1000000- 来只获取从偏移量 1,000,000 字节起的数据。

浏览器在你点击"恢复"时会自动使用这一机制。Chrome、Firefox 和 Safari 均支持从合规服务器恢复下载。大多数 CDN（Cloudflare、Fastly、CloudFront）也支持范围请求。

命令行工具控制更精细：

curl -C - -O url——从中断处恢复下载
wget -c url——效果相同
aria2c -c -s 16 url——通过 16 路并行范围请求加速下载

支持断点续传的服务

现代传输服务大多支持上传断点续传：

| 服务 | 上传续传 | 下载续传 | |---|---|---| | SwissTransfer | 支持（基于 tus） | 支持（HTTP 范围请求） | | HexaTransfer | 支持（分块 + tus 兼容） | 支持 | | WeTransfer | 支持（分块上传） | 支持 | | Dropbox Transfer | 支持 | 支持 | | Google Drive | 支持（可恢复上传 API） | 支持 | | OneDrive | 支持 | 支持 | | Box | 支持 | 支持 |

免费版有时会禁用断点续传以引导用户升级付费，但在 2026 年这种情况已较为少见。不支持断点续传的老旧服务正在逐渐淡出推荐列表，因为用户不愿忍受频繁失败。

哪些场景不自动恢复

朴素的 HTTP POST 上传不支持恢复。FTP 传输历史上表现各异——部分客户端和服务器支持 REST（重启）命令，其他则不支持。邮件附件无法恢复——Gmail 发送失败在 90% 时，只能从头开始。

基于 BitTorrent 的传输天然支持断点续传，因为 torrent 协议会追踪哪些分块已验证完成。这也是即使 Web 传输在其他方面已经追赶上来，BitTorrent 在大型发布场景下仍保持价值的原因之一。

端对端加密与断点续传

将断点续传与客户端加密结合，需要谨慎处理分块方式。文件被分割为若干分块，每个分块用 AES-256-GCM 加密（使用唯一的 IV 初始向量），再逐块上传。恢复时，客户端需要知道哪些分块已完成，并从下一个分块继续。

由于每个分块独立加密并经过认证（GCM 的 AEAD 模式），部分上传内容无法被篡改。恶意服务器若在偏移量 5 GB 处插入垃圾数据，接收方解密时会因 GCM 标签不匹配而检测到并拒绝。

HexaTransfer 等实现为每个分块的 IV 从主密钥和分块索引确定性派生，因此恢复时无需单独存储 IV。解密端通过相同的派生方式重建 IV。

客户端最佳实践

最大限度提高断点续传成功率：

上传期间保持标签页活跃。 浏览器挂起标签页会终止进行中的上传。传输服务界面通常有"请勿关闭此标签页"的提醒。
尽量接有线网络。 Wi-Fi 断开是导致失败的主因。
长时间上传期间禁用省电休眠。 macOS：caffeinate -i；Windows：使用 Powertoys Awake 工具或修改电源计划。
上传中途不要切换 Wi-Fi 网络。 TCP 连接会因 IP 变更而中断。
合上笔记本盖前等待上传完成。 现代 macOS 有时能在短暂休眠后保持上传，但并不可靠。

在服务端验证结果

部分服务显示的进度条并不能真实反映服务端状态。经历过一两次中断的上传完成后，刷新页面并验证链接是否有效——在隐身窗口中打开链接并下载一小部分。如果断点续传正常，完整文件应能正确下载。

追求万无一失时，在客户端计算文件的 SHA-256 哈希，上传完成后将下载文件的哈希与之对比。加密文件完整性校验每吉字节大约需要 10 秒 CPU，能给出绝对确定的结论。

总结

断点续传在 2026 年已是基本功能——任何不支持此功能的服务，对于几百兆字节以上的文件都是直接排除项。寻找符合 tus.io 的服务，或具备等效分块上传行为的服务。确保所选服务能优雅地处理中断；在提交大型传输任务前，先用一个小文件故意制造网络断开来测试一下。

在 hexatransfer.com 上试试 — 免费、无需注册、最多 10 GB。