WarpSend 比 FTP 快 618× 是怎么做到的

618×。这是我们的基准测试里,WarpSend 传输 1,024 个小文件比 FTP 快的倍数 —— 美东到法兰克福,真实机器,真实网络条件。

如果这个数字听起来像在吹,合理 —— 大多数「快 N 倍」的营销话术,只要你追问一句「比谁快、在什么场景下快」,就会立刻塌掉。所以下面把账算给你看,完整的。

测试条件

两台机器。一台在 us-east-1,一台在 eu-central-1。两边都是干净的连接 —— 没有流量整形,也没有人为限速。两种场景:

1. 单个 1 GB 的文件(简单情况)
2. 1,024 × 1 MB 的文件(困难情况 —— 总字节数一样,但协议层的行为差别巨大)

同一个源、同一个目的、同一个网络。唯一变化的,是传输引擎。

为什么 TCP 不适合这个距离

这是一个长肥网络问题,教科书级别的那种。

us-east-1 和 eu-central-1 之间的往返时延大约 85 ms。一条 TCP 连接的吞吐量上限是:

throughput ≤ window_size / RTT

这就是 带宽时延积 的天花板。默认接收窗口 64 KB,RTT 85 ms,你被限制在大约 750 KB/s —— 不管这条链路实际上有多少容量。在一条 10 Gbps 的管道上,这是 0.06% 的利用率。剩下 99.94% 就在那里闲着。

你可以在内核侧硬抗这个问题。更大的接收缓冲、窗口缩放、用 BBR 替掉 CUBIC、SACK、TCP offload。每一项都是真的,都是有用的,都很麻烦,都得逐台调。而 BBR —— 所有人遇事就想抓的那根稻草 —— 在 RTT 变大的时候表现也会下滑。跨洲传输时,它不是银弹。

就算所有东西都调到位了,一条 TCP 流在长距离链路上通常都很难突破 20% 的利用率,再往上你就要和路由公平性打架了。这就是 FTP、SFTP 和 rsync 共同被卡住的那个天花板。

小文件问题让事情更糟

618× 这个结果不只是 TCP 延迟在作怪。它更多来自 FTP 在面对一千个文件而不是一个大文件时的行为。

FTP 每传一个文件都会新开一组数据连接。每条新连接都要做一次 TCP 握手 —— 三个往返才能挪一个字节的有效载荷。在 85 ms 的 RTT 下,这相当于 每个文件 ~255 ms 的死时间。

1,024 files × 255 ms = 261 seconds of handshake alone

光是握手就有超过四分钟的纯开销,源端一个字节的数据都还没出去。SFTP 在这里也好不到哪去 —— 它仍然是基于 TCP 的数据包式协议,每个块还是一个「读-确认」的回合。瓶颈不是带宽,是这场对话本身。

WarpSend 的做法

三个会互相叠加的改动:

1. 带自定义可靠性的 UDP 传输。 数据包之间不再「发一个等一个」。我们的引擎在自己这边处理丢包检测、重传和顺序。这和 FASP(Aspera)、AFTP(bTrade)、GridFTP、UDT 出于同样的理由做的事是一样的 —— 它们没有一个是基于 TCP 的。代价是我们这边要多写一堆代码。回报是拥塞控制变成由我们自己调。

2. 数据包打包。 传输前,我们会扫描并把小文件打包成大块。一千个 1 MB 的文件不会再触发一千次握手 —— 它们走的是一条流,内部做帧。单文件开销基本归零。

3. 多线程流水线。 扫描、打包、加密、传输都并行跑。传输线程从不会因为等磁盘而被卡住;磁盘也不会因为等网络而被卡住。

结果是:在 1,024 文件的测试里,WarpSend 用了 ~21 秒就跑完了,FTP 花了 3.5 小时以上。在单个 1 GB 文件的测试里,差距收窄了 —— 15 秒 vs ~85 秒 —— 因为这种情况下 TCP 可以把那一次握手摊到更多数据上。

这件事什么时候最有用

618× 这个数字,对你最相关的情形是你需要经常搬大 量 文件:

• 拍摄日的原始素材(经常是几百段小片段,然后剪辑师才会合并)
• 办公室之间的项目资产(像 npm 那种几千个小文件的目录树)
• NAS 到 NAS 的备份和复制
• ML 训练数据集(经常是几百万个小张量)

任何具有「总共也才 1 GB 嘛,怎么传了三小时」这种形状的事 —— 那就是 FTP 的小文件惩罚出现在你的工作流里。

如果你想直接看,而不只是读文章,免费试用 —— 每月 1 TB 流量,不要信用卡。