FTP是一种纯TCP连接协议，因此在考虑TCP文件传输选项时，AFAIK“尽可能快”。
但是，还有一些其他产品不通过TCP运行 - 例如商业产品BI.DAN-GUN，fasp和FileCatalyst。后一个产品指出problems with pure TCP，人们可以在维基百科上阅读更多内容，例如从Network Congestion开始。
还有其他选择吗？ ..特别是开源的？此外，人们会认为这应该是一种RFC - 一种标准特定于文件传输的协议，可能在UDP上运行。有人知道这样的协议或倡议吗？ （Google SPDY很有意思，但没有直接解决快速大文件传输问题）
答案 0 :(得分：9)
为什么你认为使用TCP会使传输速度变慢？ TCP通常能够使用所有可用带宽。使用UDP代替不太可能更快。事实上，如果你试图进行可靠的基于UDP的文件传输，你可能最终会实现TCP的低级替代 - 因为你必须自己实现可靠性。
关于FTP的 问题是它为您传输的每个文件执行多个同步请求 - 响应命令，并为每个文件打开一个新的数据连接。当传输大量较小的文件时，这会导致极低效的传输，因为大部分时间都花在等待请求/响应和建立数据连接而不是实际传输数据上。
解决此问题的一种简单方法是将文件/文件夹打包到存档中。当然，您只需制作存档，使用FTP或类似方式发送存档，然后在另一侧打开包装，打包和拆包所花费的时间可能是不可接受的。您可以通过在线包装和拆包来避免这种延迟。我不知道有任何集成这种在线打包/拆包的软件。但是，您可以简单地在管道中使用nc和tar程序（Linux，在Windows上使用Cygwin）：
首先在接收器上运行：
nc -l -p 7000 | tar x -C <destination_folder>
这将使接收方等待端口号7000上的连接。然后在发送方上运行：
cd /some/folder
tar c ./* | nc -q0 <ip_address_of_receiver>:7000
这将使发送方连接到接收方，开始传输。发件人将创建tar存档，将其发送到接收器，接收器将同时提取它。如果需要，您可以反转发送方和接收方的角色（通过让接收方连接到发送方）。
这种在线tar方法没有FTP的两个性能问题;它不执行任何请求 - 响应命令，并且仅使用单个TCP连接。
但请注意，这不安全;任何人都可以在我们的发送者之前连接到接收者，向他发送他自己的tar档案。如果这是一个问题，可以使用VPN，并结合适当的防火墙规则。
编辑：您提到数据包丢失是TCP性能的问题，如果要相信FileCatalyst页面，这是一个重大问题。确实，TCP可能在高丢包链路上执行非最佳。这是因为TCP通常会对数据包丢失做出积极反应，因为它假设丢失是由于拥塞造成的;见Additive_increase/multiplicative_decrease。我不知道有任何免费/开源文件传输程序会试图通过自定义协议来解决这个问题。但是，您可以尝试不同的TCP congestion avoidance algorithms。特别是，请尝试Vegas，不使用数据包丢失作为降低传输速率的信号。
答案 1 :(得分：6)
有许多开源项目试图通过UDP解决文件传输问题。 看看UFTP，Tsunami或UDT，每个项目处于不同的发展阶段。
根据您使用的延迟和丢失的带宽，每个项目都会产生不同的结果。有一篇博客文章试图比较3个项目，这里是链接http://www.filecatalyst.com/open-source-fast-file-transfers
答案 2 :(得分：2)
不是开源，但Aspera的传输速度值得检查，不受数据包丢失或网络延迟的影响。 You can see a chart here。 它还使用名为fasp的专有协议。
答案 3 :(得分：1)
考虑使用基于UDP的文件传输，查看JSCAPE MFT Server，它实现了称为AFTP（加速文件传输协议）的专有协议。请查看此链接：
http://www.jscape.com/blog/bid/80668/UDP-File-Transfer-up-to-100x-Faster-than-TCP
请记住，JSCAPE的AFTP可以在具有网络延迟的长距离连接上发挥最佳性能。如果没有网络延迟，AFTP将不会比普通的常规FTP（通过TCP）执行任何更好的操作。
是的我为JSCAPE LLC工作。