大量小文件传输为什么很慢？原因与加速方法
小文件会逐笔重复 metadata、开关档与网络往返。本文说明如何诊断瓶颈，并测试打包、持续连接与有限并行等改善方式。
同样是 100 GB，一个视频档可能很快传完，含有数万个素材的文件夹却要等更久。差别在于每个文件都需要枚举、打开、读写元数据与创建目的文件，有些操作还必须等待远程回应。
先比较大文件、真实文件夹与封装后的文件夹，再观察网络、CPU 与磁盘使用率。这能判断封装、重用连接或有限并行是否有效，也能避免在存储已饱和时继续增加传输工作。
文件数为什么会改变传输时间
可以用这个模型理解：
总时间 ≈ 有效数据时间 + 文件清单工作 + 逐档成本 + 存储工作 + 验证
有效数据时间是大多数带宽计算器显示的部分。100 GB 通过持续 1 Gbps 路径有可计算的下限，但文件夹不只有字节。每个文件可能需要：
- 读取路径、大小、权限与时间戳记。
- 打开来源文件。
- 声明或协调下一次传输。
- 打开或调度数据工作。
- 创建目的文件。
- 发送有效数据。
- 落盘、关闭并记录完成。
- 视需要计算哈希或验证。
有些实作可以重叠这些步骤，有些大多串行。无论哪一种，文件数越多，就有越多不会反映在总容量上的工作。
Microsoft 对 SMB 也记载同样现象：小文件拷贝把较高比例时间花在创建文件、通信协议与文件系统操作，而不是搬有效数据。Microsoft：SMB 文件传输过慢
传统 FTP 将控制连接与文件数据连接分开，因此处理文件夹时可能反复支付连接与协调成本。RFC 959：File Transfer Protocol
rsync 可以重叠运行文件传输的不同阶段，新版本也能在完整扫描前开始递归传输，但仍要枚举项目并处理元数据。请参考 rsync man page与WAN 上 rsync 过慢的诊断指南。
选择修正方式前先诊断瓶颈
| 信号 | 可能瓶颈 | 第一个控制测试 |
|---|---|---|
| 字节开始移动前等很久 | 枚举、文件清单、筛选规则或校验码 | 记录第一笔有效数据时间与检查的文件数 |
| 大文件很快、文件夹很慢 | 逐档元数据或串行协调 | 比较每秒文件数与目的端 IOPS |
| 本地文件夹拷贝也慢 | 来源或目的端文件系统 | 测量本地创建／打开／关闭吞吐 |
| CPU 满载、线路闲置 | 哈希计算、加密、压缩或扫描 | 一次只改一个 CPU 密集设置 |
| 网络与存储都未充分使用 | 应用并行或等待 | 逐步增加有限并行 |
| 工作进程越多反而越慢 | 存储、CPU、内存或队列争用 | 回到中位数最佳值，而非最高工作进程数 |
简单的延迟范例
假设在 RTT 100 ms 的两个端点间传 100 GB：
- **工作 A：**一个 100 GB 文件
- **工作 B：**100,000 个平均 1 MB 的文件
有效数据总量相同，但文件操作数完全不同。
如果每个文件只多一个串行的网络往返，简化后的等待时间就是：
100,000 个文件 × 0.1 秒 = 10,000 秒
还没算有效数据、磁盘、加密与验证，就多出 2 小时 46 分钟。实际工具可能会处理流程请求、重用工作阶段或使用多条串流，因此这不是每个协议的预测；它只说明逐档延迟为何重要。
同样模型在 2 ms LAN 约为三分钟；跨洲 100 ms 则以小时计。
实际复制大量小文件的结果
2026 年 9 月，我们在德国与美国两台 VM 之间（往返时间约 141 ms）复制了 65,536 个 4,096 字节的文件，合计 268.4 MB。OpenSSH 的递归 SFTP 客户端会逐个处理文件，五次测试都没有在 15 分钟上限内完成。rsync 与通过 SSH 的 tar 流不必等前一个文件结束就能继续发送数据，两者都以约 10 MB/s 完成。每次测试结果、另外进行的 TCP 与 QUIC 测试，以及本次设置的局限，请见大量小文件传输实测。测试方法与记录的结果也公开在基准测试研究页（英文）。
小文件传输背后的四个瓶颈
1. 逐档网络往返
交互频繁的协议会在步骤之间等待远程确认或协调。距离把微小等待变成重复成本。
2. 文件系统元数据与开关档
来源必须枚举目录并读取元数据，目的端要创建项目、更新元数据并落盘。高速网络无法移除存储 IOPS 上限。
3. 串行的哈希计算、加密与调度
若工具先扫完整棵树、再哈希值全部、再加密，最后才开始送，阶段之间网络会闲置。最慢的串行阶段决定完整耗时。
4. 太小的有效数据无法填满路径
小文件可能在单一串流累积到足以利用高带宽、高延迟路径之前就结束。如果应用不断暂停，标示 1 Gbps 也没有意义。
先创建 ZIP 为什么通常有效
把文件夹封装后再传，可以把大量文件操作转成一条连续串流。这也是系统管理经常建议 tar 或 ZIP 的原因。
但它只是把工作移到别处：
- 发送端可能需要压缩档暂存空间。
- 接收端解压缩时还需要一份空间。
- 封装与解压缩都增加总耗时。
- 一个文件变更可能要求重建或重传大型压缩档。
- 若工具没有索引，续传与验证以整包为单位。
偶尔传一次文件夹，封装可能是最简单答案。固定制作流程则应由传输系统自行处理批量封装。
WarpSend 的并行封装如何改善
WarpSend 把文件夹当成连续传输工作，而不是互不相关的上传队列。
并行封装处理流程会重叠：
- 目录扫描
- 内容哈希计算
- 批量封装与调度
- 加密
- 网络传输
- 目的端写入
有限并行让工作保持流动，不必把整个目录加载内存。持续加密处理流程也能避免长距离路径在每个文件的单一步骤完成前闲置。
比较当前版本时，使用相同文件、路径、存储设备与安全设置，分别记录传输阶段速度及取得验证后文件的完整交付时间。WarpSend 与 FTP 测试方法说明如何进行比较；FTP 结果也不能代表 SFTP 或 Aspera 的性能。
完整方法请见WarpSend 与 FTP 基准测试。
并行封装何时有帮助、何时没有
适合：
- 文件夹有数百或数千个文件。
- 端点间 RTT 高。
- 固定发送媒体素材、项目树、数据集或 NAS 文件夹。
- 必须保留加密、续传与验证。
- 手动封装与解压的营运成本高。
帮助较小：
- 工作已经是一个大型连续文件。
- 两端都在同一低延迟 LAN。
- 存储设备比网络慢。
- 调校后传输已达路径的实际上限。
干净路由上的单一大文件，调校后 FTP 可以非常快。文件型态会改变比较结果。
如何测试自己的文件夹
准备总容量接近的三组数据：
- 一个大文件。
- 约 16 个文件的中型批量。
- 1,000 或 100,000 个小文件的批量。
每轮记录：
- 文件数与平均大小
- 来源与目的端存储
- 带宽、RTT、丢包
- 加密与验证设置
- 完成时间
- 传输阶段吞吐量
- 密码学验证结果
每种工作量都要重复，回报中位数而非最快一轮。使用你实际要部署的路由与硬件。
规划有效数据部分可用文件传输时间计算器，距离影响请看长距离网络高速文件传输。
用具代表性的文件夹开始 WarpSend 传输，再把完整耗时、验证与复原行为和目前流程比较。
常见问题
为什么大量小文件比同容量的一个大文件慢？
每个小文件都会增加目录枚举、元数据读取、开关档、目的端创建、调度与网络协调。一个大文件能把固定工作分摊到连续有效数据上，大量小文件则会重复数千次。
传输数千个文件前应该先创建压缩档吗？
压缩档可以把大量文件操作转成一条串流，适合一次性工作。但要把压缩档创建、暂存磁盘、解压缩、续传粒度与验证都算进墙钟时间。固定流程可能更适合保留文件边界的自动批量封装。
增加并行传输一定能加速小文件吗？
不一定。有限并行可以重叠网络与存储工作，但工作进程太多会争用磁盘 IOPS、CPU、内存、文件句柄与网络队列。请逐步增加，当完成时间中位数不再改善时就停止。
如何对小文件传输做基准测试？
用总容量接近的单一大文件、中型批量与真实小文件文件夹比较。记录文件数、存储、RTT、丢包、CPU、加密、验证、第一笔有效数据等待时间、墙钟完成时间，以及重复运行的中位数。