通过网络传输文件的最快方法是什么（FTP、HTTP、RSync 等）[关闭]答案

【问题标题】：What is the fastest way to transfer files over a network (FTP, HTTP, RSync, etc.) [closed]通过网络传输文件的最快方法是什么（FTP、HTTP、RSync 等）[关闭]
【发布时间】：2012-03-31 06:18:18
【问题描述】：

我正在尝试找出通过网络在两个系统之间传输大量数据的最佳方式。我目前正在研究 FTP、HTTP 或 RSync，我想知道哪个是最快的。我在网上找了一些答案，找到了以下网站：

问题在于这些都是旧的，并且更多地谈论协议之间的通信方式之间的理论差异。我对实际基准测试更感兴趣，可以说对于特定设置，在传输不同大小的文件时，一种协议比其他协议快 x%。

有没有人测试过这些并将结果发布在某个地方？

【问题讨论】：

FTP 在处理许多小文件时总是非常缓慢。
如果您有 ssh，tar + gzip 管道是一种快速而简单的解决方案。 tar -cf - | gzip | ssh user@host tar -xvf -。有很多小文件比 ftp 快得多。至少如果你从 Linux 转移到 Linux，我过去在 bsdtar 上遇到过问题。
FASP 协议是传输文件的最快方式。检查 IBM Aspera 项目。 pacgenesis.com/tcp-vs-udp-vs-fasp-which-is-the-fastest-protocol/….

标签： http networking file-upload ftp rsync

【解决方案1】：

好的，所以我设置了以下测试：

硬件：2 个台式机 Intel Core Duo CPU @ 2.33GHz，4G RAM。
操作系统：两台机器上的 Ubuntu 11.10
网络：100Mb 专用交换机，两台机器都连接到它。
软件：
- Python HTTP 服务器 (inspired by this)。
- Python FTP 服务器 (inspired by this)。
- Python HTTP 客户端 (inspired by this)。
- Python FTP 客户端 (inspired by this)。

我将以下几组文件上传到每个服务器：

1 100M 文件。
10 个 10M 文件。
100 个 1M 文件。
1,000 个 100K 文件。
10,000 个 10K 文件。

我在多次运行中得到以下平均结果（以秒为单位）：

|-----------+---------+----------|
| File Size | FTP (s) | HTTP (s) |
|-----------+---------+----------|
|      100M |       8 |        9 |
|       10M |       8 |        9 |
|        1M |       8 |        9 |
|      100K |      14 |       12 |
|       10K |      46 |       41 |
|-----------+---------+----------|

因此，似乎 FTP 在大文件中稍快一些，而 HTTP 在许多小文件中稍快一些。总而言之，我认为它们是可比的，服务器实现比协议重要得多。

【讨论】：

很高兴看到 scp 和几个 rsync 变体（带/不带压缩，--inplace 等...... :)
还记得上面所说的关于协议的内容，如果你可以设置一些在协议中没有太多开销的东西，例如 UDP，并且你有可靠的网络传输，它可以更快地传输大大地。这是 StackOverflow 上的讨论：stackoverflow.com/questions/47903/…
多年后，感谢您的回答和努力。

【解决方案2】：

如果每一端的机器都相当强大（即不是上网本、NAS 盒、烤面包机等），那么我希望所有通过 TCP 工作的协议在传输大量数据时的速度大致相同。应用程序协议的工作实际上只是填充一个缓冲区供 TCP 传输，所以只要他们能保持它充满，TCP 就会设定节奏。

执行压缩或加密的协议可能会在功能较弱的机器上成为 CPU 的瓶颈。我的上网本的 FTP 比 SCP 快得多。

rsync 做了一些聪明的事情来快速传输增量更改，但对于批量传输，它与笨拙的协议相比没有优势。

【讨论】：

【解决方案3】：

另一个要考虑的实用程序是 bbcp：http://www.slac.stanford.edu/~abh/bbcp/。

这里有一个很好但过时的使用教程：http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm。我发现 bbcp 非常擅长传输大文件（多 GB）。根据我的经验，它平均比 rsync 快。

【讨论】：

我之前无法添加这个额外的链接，因为我没有足够的声誉。这是我发现它的地方：moo.nac.uci.edu/~hjm/HOWTO_move_data.html。这个链接描述了一堆不同的程序以及它们之间的优缺点。

【解决方案4】：

rsync 可选择压缩其数据。这通常会使传输速度更快。见rsync -z。

你没有提到 scp，但scp -C 也压缩了。

请注意，压缩可能会使传输速度更快或慢，具体取决于您的 CPU 和网络链接的速度。（较慢的链接和较快的 CPU 使压缩成为一个好主意；更快的链接和较慢的 CPU 使压缩成为一个坏主意。）与任何优化一样，请在您自己的环境中衡量结果。

【讨论】：

告诉我更多关于 FTP 如何选择性地压缩数据的信息。我对此不熟悉。
感谢您告诉我这件事。我不知道 MODE Z。但是，由于它不是标准化的，我使用的任何一个 FTP 客户端都不支持，我连接的 FTP 服务器也不支持，我会支持我的建议使用rsync -z。
使用 rsync -z 可以显着降低传输速率，这在慢速链接中可能有意义，在本地网络中它实际上会减慢速度，具体取决于主机。

【解决方案5】：

恐怕如果您想知道您的需求和设置的答案，您要么必须更具体，要么自己进行性能（和可靠性）测试。至少对所讨论的协议及其通信有基本的了解确实会有所帮助，因此我认为您引用的文章是有用的资源。它还有助于了解这些协议的早期发明者面临哪些限制——他们的目标是保持较低的网络影响，他们是否内存不足，或者他们是否必须计算他们的 CPU 周期？如果您想获得适合您情况的答案，请考虑或回答以下几点：

操作系统/文件系统相关：
- 您是在相同的 OS/FS 组合之间进行复制，还是必须担心不兼容问题，例如在接收端没有匹配的文件类型？
- 即你有什么特别要运输的吗？元数据、资源分支、扩展属性、文件权限可能只是无法通过您选择的协议/工具传输，或者在接收端毫无意义。
- 稀疏文件也是如此，它们最终可能会在副本的另一端膨胀到完整大小，从而破坏您可能对大小调整的所有计划。
物理约束相关：
- 网络影响
- cpu 负载：如今，压缩“便宜”得多，因为现代 CPU 受到压缩的挑战比设计大多数传输协议时的 CPU 更少。
- 容错 - 您是否需要能够从中断的传输离开您的地方重新开始，或者您更愿意重新开始？
- 增量传输还是完全传输？增量传输是否会为您节省大量资金，或者您是否根据任务设计进行了完全传输？在后一种情况下，在开始传输之前构建传输列表所增加的延迟和内存影响将是不太理想的权衡。
- 该协议在利用底层网络协议可用的 MTU 方面有多好？
- 您是否需要保持稳定的数据流，例如在接收端保持磁带驱动器流式传输？

有很多事情需要考虑，而且我敢肯定列表还不完整。

【讨论】：