当通过各种文件传输方式（如 FTP、SFTP、NFS 和 Samba）传输大量（几 GB）数据时，它们都面临相同的问题，即多个小文件有时会将速度降低到 MB 或 KB - 即使在 10Gbps 链路上也是如此。
但是，如果我在传输之前对整个文件夹进行 zip、tar 或 rar 压缩，那么网络链接就会完全饱和。
是什么造成了这种影响？
如何才能提高通过网络传输许多单独小文件的大型文件的性能？
在可用的文件传输协议中，哪一个最适合此目的？
我对网络拥有完全的管理权，因此所有配置和选项都可用，例如在网络接口上设置 MTU 和缓冲区大小以及关闭文件服务器配置中的异步和加密，这些都是一些一次性的想法。
答案1
文件系统元数据。系统管理员低估了使文件成为可能所需的开销。直到他们尝试处理许多小文件。
假设您有一百万个 4 KB 的小文件，一个具有 8 个驱动器主轴的相当快的存储，以及一个 10 Gb 链路，该阵列有时会因连续读取而饱和。进一步假设每个主轴 100 IOPS，每个文件需要一个 IO（这过于简单，但说明了这一点）。
$ units "1e6 / (8 * 100 per sec)" "sec"
* 1250
/ 0.0008
21 分钟！相反，假设一百万个文件位于一个存档文件中，并且顺序传输会使 10 Gb 链路饱和。80% 的有用吞吐量，由于被包裹在以太网中的 IP 中。
$ units "(1e6 * 4 * 1024 * 8 bits) / (1e10 bits per second * .8)" "sec"
* 4.096
/ 0.24414062
4秒相当快。
如果底层存储是小文件，那么任何文件传输协议都会对其中许多文件产生问题。当阵列的 IOPS 成为瓶颈时，其上的文件服务器的协议实际上并没有帮助。
最快的是复制一个大型档案或磁盘映像。主要是顺序 IO，文件系统元数据最少。
也许使用文件服务协议，您不必复制所有内容。挂载远程共享并访问所需的文件。但是，访问包含大量文件的目录或复制所有文件仍然很慢。（请注意，NFS 服务器意外消失可能会导致客户端永远卡在 IO 中。）
答案2
每个单独的文件传输都是一个事务，每个事务都有与之相关的开销。粗略的例子：
- 客户端告诉服务器：“我要发送一个文件，文件名是example.txt，大小为100字节”。
- 服务器告诉客户端：“好的，我准备好接收了”。
- 客户端向服务器发送100字节的文件数据。
- 服务器向客户端确认已收到文件，并关闭本地文件句柄。
在步骤 1、2 和 4 中，客户端和服务器之间需要进行额外的往返，这会降低吞吐量。此外，这些步骤中发送的信息会增加要传输的总数据量。如果元数据为 20 字节，那么对于 100 字节的文件来说，这将是 20% 的开销。
没有办法避免协议上每个文件的开销。