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

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

http networking file-upload ftp

通过网络传输文件（FTP、HTTP、RSync等）的最快方式是什么,http,networking,file-upload,ftp,rsync,Http,Networking,File Upload,Ftp,Rsync,我试图找出在两个系统之间通过网络传输大量数据的最佳方法。我目前正在研究FTP、HTTP或RSync，我想知道哪一种是最快的。我在网上查找了一些答案，发现了以下网站：问题是这些协议都很古老，而且更多地讨论了协议之间通信方式的理论差异。我对实际的基准测试更感兴趣，也就是说，对于特定的设置，当传输不同大小的文件时，一种协议比其他协议快x% 有人测试过这些并将结果发布到某处吗？rsync可以选择压缩数据。这通常会使传输速度更快。看你没有提到scp，但也提到了压缩请注意，压缩可能会使传输变快

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

问题是这些协议都很古老，而且更多地讨论了协议之间通信方式的理论差异。我对实际的基准测试更感兴趣，也就是说，对于特定的设置，当传输不同大小的文件时，一种协议比其他协议快x%

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

rsync可以选择压缩数据。这通常会使传输速度更快。看

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

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

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

在功能较弱的机器上，进行压缩或加密的协议可能会在CPU上出现瓶颈。我的上网本的FTP速度比SCP快得多

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

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

硬件：2台台式机Intel Core Duo CPU@2.33GHz，4G内存
操作系统：两台机器上都安装了Ubuntu11.10
网络：100Mb专用交换机，两台机器都连接到它
软件：
- Python HTTP服务器（）
- Python FTP服务器（）
- Python HTTP客户端（）
- Python FTP客户端（）

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

100M文件

10万个文件

1001M文件

10万个文件

10000个10K文件

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

所以，看起来FTP在大文件中稍微快一点，而HTTP在许多小文件中稍微快一点。总而言之，我认为它们具有可比性，服务器实现比协议更重要。

如果您想知道您的需求和设置的答案，恐怕您必须更具体，或者自己进行性能（和可靠性）测试。它有助于至少对所讨论的协议和它们的通信有基本的了解，所以我会考虑你们引用了有益的资源的文章。这也有助于了解这些协议的早期发明者所面临的限制——他们的目标是保持低网络影响，是内存不足，还是必须计算cpu周期？如果你想得到适合你的情况的答案，这里有一些事情需要考虑或回答：

操作系统/文件系统相关：
- 您是在同一OS/FS组合之间进行复制，还是必须担心不兼容，例如接收端没有匹配等效文件的文件类型
- 也就是说，你们有什么特别的东西要运输吗？元数据、ressource分叉、扩展属性、文件权限可能无法通过您选择的协议/工具传输，或者在接收端没有意义
- 稀疏文件也是如此，它最终可能会在副本的另一端膨胀到完整大小，从而破坏所有关于大小调整的计划
相关的物理限制：
- 网络影响
- cpu负载：如今，压缩要“便宜得多”，因为与大多数传输协议设计时相比，现代cpu受压缩的挑战更小
- 失败容忍度-你是否需要能够从中断的传输中恢复过来，或者你更愿意重新开始
- 增量转移，还是完全转移？增量转移是否为您带来了巨大的节约，或者您的任务设计是否有完整的转移？在后一种情况下，在开始传输之前构建传输列表所增加的延迟和内存影响将是一个不太理想的折衷
- 协议在利用底层网络协议提供的MTU方面有多好
- 您是否需要保持稳定的数据流，例如在接收端保持磁带机的流式传输

需要考虑的事情很多，我确信这个列表还没有完成。

< P>另一个要考虑的实用程序是BBCP:.

这里有一个很好但过时的使用指南：。我发现bbcp非常擅长传输大文件（多个GB）。根据我的经验，它平均比rsync快。

FTP在许多小文件上总是非常慢。如果您使用ssh，tar+gzip管道是一个快速而简单的解决方案<代码>tar-cf-| gzip | sshuser@hosttar-xvf-。使用大量小文件比ftp快得多。至少如果您从Linux传输到Linux，我在过去遇到过bsdtar问题。FASP协议是传输文件的最快方式。检查IBM Aspera项目。告诉我更多关于FTP如何选择性地压缩数据的信息。我不熟悉，谢谢你告诉我。我不知道模式Z。但是，由于它不是标准化的，我使用的FTP客户端都不支持它，我使用的FTP服务器也不支持它

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