通过网络传输文件的最快方式是什么（FTP，HTTP，RSync等）

Question

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

• http://daniel.haxx.se/docs/ftp-vs-http.html
• http://www.isi.edu/lsam/publications/http-perf/

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

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

Answer 1

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

• 硬件：2台台式机Intel Core Duo CPU @ 2.33GHz，内存4G。
• OS：两台机器上的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. 1 100M档案。
2. 10个10M文件。
3. 100个1M文件。
4. 1,000个100K文件。
5. 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速度要快一些。总而言之，我认为它们具有可比性，服务器实现比协议更重要。

Answer 2

如果每端的机器相当强大（即不是上网本，NAS机箱，烤面包机等），那么我希望所有通过TCP工作的协议在传输批量数据时的速度大致相同。应用程序协议的工作实际上只是填充TCP传输的缓冲区，因此只要它们能够保持完整，TCP就会设置速度。

执行压缩或加密的协议可能会在功能较弱的计算机上阻塞CPU。我的上网本比FTP快得多。

rsync可以快速传输增量更改，但对于批量传输而言，它没有优于dumber协议的优势。

Answer 3

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

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

Answer 4

rsync可选择压缩其数据。这通常会使转移速度更快。请参阅rsync -z。

您没有提到scp，但scp -C也会压缩。

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

Answer 5

我担心如果您想知道您的需求和设置的答案，您要么必须更具体，要么进行自己的性能（和可靠性）测试。它确实有助于至少基本了解有关协议及其通信，因此我认为您引用的文章是一个有用的资源。它还有助于了解这些协议的早期发明者面临哪些限制 - 他们的目标是保持低网络影响，他们是内存匮乏，还是他们必须计算他们的cpu周期？如果您想根据自己的情况找到答案，可以考虑或回答以下几点：

• OS /文件系统相关：
  • 您是在相同的OS / FS组合之间复制还是必须担心不兼容，例如文件类型没有匹配接收端的等效文件？
  • 即。你有什么特别的交通工具吗？元数据，资源分支，扩展属性，文件权限可能不是由您选择的协议/工具传输，也不会在接收端无意义。
  • 对于稀疏文件也是如此，这可能最终会在副本的另一端膨胀到完整大小，从而破坏了您可能有关于调整大小的所有计划。
• 相关的物理限制：
  • 网络影响
  • cpu load：现在，压缩要“更便宜”，因为现代CPU受压缩的影响要小于大多数传输协议设计时的压缩。
  • 容错 - 您是否需要能够在中断转移的地方找到您，或者您是否愿意重新开始？
  • 增量转账还是全额转账？增量转移是否会为您带来任何大的节省，或者您是否通过设计任务完全转移？在后一种情况下，在开始转移之前建立转移列表所增加的延迟和内存影响将是一个不太理想的权衡。
  • 协议在利用底层网络协议可用的MTU方面有多好？
  • 您是否需要保持稳定的数据流，例如在接收端保持磁带机流式传输？

需要考虑很多事情，我确信列表还不完整。