为什么你认为使用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拥塞避免算法。特别是,请尝试Vegas,它不使用数据包丢失作为减少传输速率的信号。