加快高延迟网络上的SFTP上传速度？

我正在尝试使用SFTP在国际上传输一组大文件，但是我发现我的国际合作伙伴尽管两边的连接都很好，但上传速度无法达到约50k以上。我们可以以此速度上载多个连接（因此不能上带宽吗？），但是没有一个上载可以提高速度，这是一个问题，因为许多文件的大小只有几GB。

使用标准的Apple OSX“远程登录” SFTP系统托管SFTP。

有没有办法提高上传速度，还是有其他的SFTP主机会有所帮助？我不清楚这是配置问题还是协议的固有限制。

（出于安全原因，我需要使用端到端加密的对等连接-无需云服务）。

使用OpenSSH sftp客户端（您似乎正在使用），可以使用：

• -R切换为增加请求队列长度（默认为64）
• -B切换以增加读/写请求的大小（默认为32 KB）

首先，尝试将两者加倍：

sftp -R 128 -B 65536 user@host

可能没什么大不了的，您增加其中的哪个。

增大任一值都应有助于使高延迟连接饱和。使用上述设置，它将随时保持8 MB的数据在管道中流动（128 * 64K = 8M）。

请注意，这仅适用于大文件传输。传输许多小文件时，它不会有任何效果。

有关其他（GUI）SFTP客户端的背景知识和讨论，请参阅我的答案的“网络延迟/延迟”部分，以了解为何FileZilla SFTP文件的最大传输上限为1.3MiB / sec，而不是使可用带宽饱和？rsync和WinSCP甚至更慢。

您可以尝试启用压缩，然后查看是否有帮助。

来自man sftp：

-C 启用压缩（通过ssh的-C标志）。

来自man ssh：

-C 请求压缩所有数据（包括stdin，stdout，stderr和用于转发的X11，TCP和UNIX域连接的数据）。压缩算法与gzip（1）所使用的算法相同，并且“级别”可以由协议版本1的CompressionLevel选项控制。压缩在调制解调器线路和其他慢速连接上是理想的，但只会减慢快速网络上的速度。可以在配置文件中逐个主机设置默认值。请参阅压缩选项。

听起来好像连接可能在其路径上的某个点受到速率限制（或者，对我来说，这似乎是对每个连接50kB / s的最简单解释，但可能有多个这样的连接），尽管它可能不是确保两侧的磁盘都不成问题的好主意。

您还可以运行一个快速的pcap命令来查看是否存在任何“显而易见的”问题（例如大量的重传）-但除非您有一定的信心，您将能够解决此问题，我可能只会看看启用压缩是否会救命。

我正在尝试使用SFTP在国际上传输一组大文件

还没有提到它作为答案，但是当通过高延迟链接传输多个文件时，有一种非常简单的解决方案来获得更好的性能：

并行传输多个文件。

这是您甚至在问题中提到的解决方案。用它。

基本上，TCP协议不能很好地处理具有大带宽延迟产品的连接-单个连接无法一次保持足够的数据移动。参见https://en.wikipedia.org/wiki/TCP_tuning

由于每个连接都受TCP协议限制，因此只需使用更多连接即可。

加快sftp传输

假设您的问题是每个TCP连接的网络调整和/或限制，请使用lftp镜像子系统查看sftp

两端的网络调优是一个更大的主题，并且需要大量的来回操作，这使该主题超出了ServerFault的范围。对于单个连接，iwaseatenbyagrue提到的压缩可能会有所帮助。假设远端允许压缩。

（您在问题标题中提到了“高延迟”，但在正文中未提及。您是否测量了实际延迟，结果如何？）

OpenSSH的一个补丁可显着提高高延迟网络链接上的吞吐量：HPN-SSH：（强调我的）

SCP和OpenSSH中底层的SSH2协议实现受静态定义的内部流控制缓冲区限制的网络性能。这些缓冲区通常最终成为SCP网络吞吐量的瓶颈，特别是在长带宽和高带宽的网络链路上。修改ssh代码以允许在运行时定义缓冲区可以消除此瓶颈。我们创建了一个修补程序，该修补程序将消除OpenSSH中的瓶颈，并且可以与其他服务器和客户端完全互操作。此外，HPN客户端将能够更快地从非HPN服务器下载，并且HPN服务器将能够更快地从非HPN客户端接收上传。

因此，请尝试在接收方编译和使用HPN-SSH，并查看它是否可以提高传输速度。

不知道这是否适合您，但是您是否尝试过将数据推送到国际站点？以及在不同时间查看是否与网络资源争用有关？

我们可以以这种速度上传多个连接（因此带宽不行吗？）

听起来像是配置问题-故意地（作为无需额外配置就提供服务的一种方式）或偶然地（例如，窗口缩放损坏）或交通管制过大）。虽然您可以并行化传输，但是您没有告诉我们连接另一端的内容，或者是否值得开发一些简单的脚本来处理文件的分片/重组。

调整队列大小和压缩不太可能产生任何重大影响，除非原因是编写的软件非常差（并且openSSH不在此类别之内-在使用带有更长请求队列/更大块大小的openssh时没有多大意义，除非延迟是超过250毫秒。您可以考虑尝试使用来自不同位置的不同客户端来排除服务器问题。

我的第一个电话将是确定是问题的责任在于哪个提供商，请他们解决问题或切换到其他提供商。