并行上传技术：最大化传输带宽
了解并行上传如何显著加速文件传输。理解分块上传和多连接传输。
并行上传将文件拆分成若干分块（通常每块 5—100 MB），并通过多个并发 TCP 连接同时推送，从而绕过单流在高延迟链路上遇到的吞吐量上限。Amazon S3 Multipart Upload、Google Cloud Storage 可恢复上传和 tus.io 均实现了这一机制。在延迟 80 ms、带宽 1 Gbps 的链路上，单个 HTTP PUT 请求的吞吐量通常只能达到约 150 Mbps，而 8 路并行流则能突破 900 Mbps。这种提升是真实且可预测的——一旦理解了原因，就能合理运用。
为什么单流远远不够
TCP 的拥塞控制通过滑动窗口来决定允许多少未确认数据在途。在高带宽、高延迟的链路上，默认窗口大小（Linux 5.x 约 16 MB，旧版内核更小）在 ACK 返回之前就已耗尽，发送方被迫空等。这就是"带宽时延积"问题，也是为什么即使在千兆线路上，从巴黎向新加坡服务器发起单次 FTP 传输，速度通常只有约 30 Mbps。
多路并行连接可以规避这一问题，因为每条连接都有独立的窗口。8 路各 30 Mbps 的流合计 240 Mbps，而且 CDN 边缘节点选路有时会将不同连接路由到不同的入口点，效果进一步叠加。
分块大小与并发数的选择
最优配置取决于延迟和丢包率。同一大陆、往返时间低于 50 ms 的传输，10 MB 分块搭配 4 个并发 worker 基本能跑满大多数家用上行带宽。跨洲际或高丢包移动链路（往返时间超过 100 ms、丢包率超过 0.5%），应降到 5 MB 分块搭配 8—16 个 worker。
S3 Multipart API 要求每个分块最小 5 MB（最后一块除外），最大 5 GB，每次上传最多 10,000 个分块，理论上限约 48.8 TB。Google Cloud Storage 每次合并最多 32 个分块，可恢复会话 URI 有效期最长一周。Azure Blob 块存储每个对象最多可接受 50,000 个块，每块最大 4000 MiB。
对于基于浏览器的传输，超过 100 MB 的分块会给已有负载的标签页带来内存压力，因此大多数 Web 界面将分块大小控制在 5—20 MB 之间。
主流传输服务的实际实现
WeTransfer 的 Web 上传器将文件拆成 6 MB 分块，并行运行 3—5 个 XHR 请求。Smash 更为激进，4 MB 分块配合最多 8 个 worker。SwissTransfer 采用 50 MB 分块搭配 4 路并行，这在瑞士光纤线路上偏向吞吐量，但在不稳定连接上表现较差，因为一个分块失败就需要重传 50 MB。Dropbox Transfer 使用 8 MB 分块的分块上传 API。
实际测试中的差异：在 500 Mbps 上传速度下传输 5 GB 文件，WeTransfer 约需 95 秒；SwissTransfer 则约需 105 秒，因为偶发的分块重试带来额外开销。
断点续传：并行上传的隐形优势
分块上传天然支持断点续传。如果在第 120 个分块中的第 47 个时 Wi-Fi 断开，无需从零重来，从第 48 个分块继续即可。tus.io 协议（开放标准，目前 2.0 版本）通过 HEAD 请求查询上传偏移量、通过 PATCH 请求追加数据来实现这一功能，使用 Upload-Offset 和 Upload-Length 头字段。
Google Drive 的可恢复上传 API 使用持续 7 天的会话 URI。笔记本崩溃、重启，重新打开标签页，仍能从断点精确继续——这是 10 GB 传输真正可用与"看运气"之间的本质区别。
客户端加密对并行上传的影响
端对端加密传输服务必须在客户端加密每个分块后再上传。现代笔记本 CPU 的 AES-256-GCM 加密速度约 500 MB/s，并非瓶颈所在——但操作顺序很重要：加密分块，上传分块，加密下一个分块。Worker 池的流水线设计在这里至关重要。朴素实现会串行化加密和上传操作，实际吞吐量减半。正确实现应让 2—4 个加密 worker 通过有界队列向 4—8 个上传 worker 持续供数据。
这就是为什么 HexaTransfer 在 Web Worker 中并行运行 AES-256-GCM 加密，同时维护一个并行 XHR 池——这样在浏览器中才能真正用到 10 GB 的上限，而不是卡在加密等待上。
背压与服务端限制
更高的并发并不总是意味着更快。如果接收方服务按 IP 进行请求限速（CloudFront 常见配置是每个发行版每秒 25,000 次请求），推送 32 个并发分块可能触发 503 Slow Down 响应。HTTP/2 有所帮助，因为它在单个 TCP 连接上多路复用，但许多 CDN 仍然在边缘节点终止 HTTP/2 后向源站发出 HTTP/1.1 请求，实际有效并发取决于边缘节点配置。
在过度并发之前先测试。8 个 worker 几乎总是安全的；16 是云存储能够干净处理的上限；32 开始产生的重试所带来的代价超过收益。
浏览器的并发限制
Chrome 和 Firefox 对每个源的并发连接数，在 HTTP/1.1 下限制为 6 个，HTTP/2 下实际上不设限。如果传输服务仍在 HTTP/1.1（现在很少见，但某些遗留 FTP-over-HTTP 网关仍是如此），无论创建多少个 worker，并行数上限都是 6。可通过开发者工具验证：网络面板的"瀑布"列会显示请求堆积等待的情况。
iOS 17 及以上版本的 Safari 能干净处理 6 个并行 XHR，但在约 1.5 GB 的内存压力下会开始驱逐后台标签页，这对维护分块上传缓冲区有影响。
并行上传无效的场景
在非对称家用宽带上（典型配置：下行 1 Gbps，上行 40 Mbps），瓶颈在于你的上行，而非服务端的接收能力。8 路并行、每路 5 MB 的分块流经 40 Mbps 的管道，不会比单流 40 Mbps 更快。并行的收益在于单流上限低于管道容量时，而非你已经在跑满链路时。
在信号差的移动网络上同理：只有一格 LTE，多开几个 worker 只会产生更多重传。
选择传输服务的判断依据
如果你在为频繁传输大文件选择工具，重点检查三点：是否支持可恢复分块上传，Web 界面运行多少个并行 worker，以及是否使用 HTTP/2 或 HTTP/3 到达边缘节点。同时满足这三点的服务，在像样的网络连接下几分钟内就能传输完 10 GB 文件。
在 hexatransfer.com 上试试 — 免费、无需注册、最多 10 GB。