WarpSend vs FTP 基准测试：小文件传输的 40 倍差距

跨国交付数百个小文件时，时间往往花在文件之间的等待，而不只是数据发送本身。在已有的 256 个、每个 1 MiB 小文件测试中，WarpSend 的整次任务平均速率中位数约为 FTP 基准的 40 倍。要理解这个差距，需要看每个文件发送前后，工具还做了哪些工作。

这也是 WarpSend 批处理特别能发挥作用的场景：一个包含许多独立素材的项目文件夹。至于大型单文件，后续美国至德国的完成记录也已有超过 200 MB/s 的平均传输速度。

256 个小文件，约 40 倍的速率差距

这组比较使用随机生成的测试文件，文件夹总容量为 256 MiB，传输方向为德国至美国，往返延迟约 143 ms。两端均为 Linode 服务器，配置 2 vCPU 与约 4 GB 内存。FTP 基准使用 curl 搭配 vsftpd 进行被动模式上传，并设置 BBR 与较大的 TCP 缓冲区。

三次 WarpSend 结果约为 FTP 基准的 38–42 倍，中位数比值为 24.6 / 0.61 = 40.3。这里使用完整发送命令的耗时计算，因此文件夹的准备与完成处理，也已计入结果。

测试记录采用 2026 年 7 月 10 日的 FTP 基准，以及同一路径上 7 月 11 日的 WarpSend 开发版本测试。FTP 未加密，WarpSend 则包含端点加密传输流程；约 40 倍的差距对应的是这组文件与设置。

为什么小文件能拉开这么大的差距？

一个由相机原始素材、项目文件、缩略图与元数据组成的文件夹，需要传输工具找到并处理其中每一个文件。即使网络还有带宽，文件之间的短暂等待也会逐渐累积。这也是为什么只看文件夹的总容量，还不足以估计交付时间。

FTP 使用分开的控制连接与数据连接，这个架构定义于 RFC 959。如果客户端为每个文件建立数据连接，就会在整个文件夹的传输过程中反复执行连接准备与完成确认。跨国路径上的往返延迟，可能让连接在两个文件之间等待。客户端如何处理连接，以及同时发送多少文件，都会影响这些等待能否重叠进行。

WarpSend 通过批处理与重叠执行文件处理阶段，减少这类任务的空档。前一批数据正在发送时，后续文件可以接着准备，让传输持续进行。因此，评估一个项目的交付时间，除了总容量，也要看文件数量与目录结构；单个大文件的速度无法涵盖整个文件夹的表现。

关于这个差异，可接着阅读大量小文件传输为什么慢，以及 FTP 长距离传输变慢的原因。

大型单文件，也有超过 200 MB/s 的完成记录

以下三次已完成传输均使用 WarpSend 的 Tunnel 路径，由 US-ContentServer 发送至 DE-ContentServer。发送的文件为 large-2048mb.bin，界面显示大小为 2.15 GB。

数值来自 WarpSend 传输历史。速度使用十进制 MB/s，耗时按应用程序显示取整数。这三条记录呈现该路径当时的表现；其他路径的速度仍会受可用带宽、端点硬件与存储设备影响。

这里是应用程序记录的大文件传输区间速度；前面的小文件表则采用整个命令的平均速率。两组数据的文件组成、日期与方向不同，各自用于说明对应工作负载的表现。

对项目交付的实际意义

单个大文件的速度，只呈现交付流程的一部分。相机附属文件、缩略图、项目素材与其他小文件，可能让反复准备的时间成为主要等待。小文件测试呈现的差距，正好说明减少这些重复工作有多重要：网络有带宽，不代表文件夹就能持续快速传送。

对于大型成片，超过 200 MB/s 的记录呈现 WarpSend 在该美国至德国路径上的持续传输表现。对于整个文件夹，批处理与重叠执行的文件处理流程，则有助于减少文件之间的空档。当交付内容同时包含影音素材与制作项目，这两种能力都派得上用场。

WarpDirect可在安装 WarpSend 的设备之间发送文件，包括支持的桌面系统与 NAS。在两端安装 WarpSend后，选择源文件与接收设备即可开始。如果要了解特定路径的网络与存储限制，可参考长距离传输指南。