我正在从服务器上下载，使用FileZilla以1.3MiB /秒的速度下载，但我可以开始并发下载，并且也将以1.3MiB /秒的速度下载。 那么，为什么我不能以高于1.3MB / s的速度下载一个文件，接近饱和可用带宽（〜6 + MB / s）呢？
我知道我可以使用其他一些支持分段下载的SFTP客户端，比如lftp，知道其他开源的好东西吗？
但是我还是想知道将下载一个文件限制在1.3MB / s是什么限制，用TCP和缓冲区等一些技术限制还是一些configuration问题？ 我检查并确定FileZilla中没有启用stream量限制。
另外我尝试了rsync，它比FileZilla / SFTP更糟糕。 我也尝试过WinSCP，而且不pipe方法SCP / SFTP都是最慢的。 所以在1.3MB / s的不断传输下，FileZilla与其他传输方式相比是相当不错的。
如果有人有一个很好的解释，为什么传输高峰在1.3MB /秒，我真的很想知道，如果有可能增加这一点，而不诉诸使用分段下载。 服务器运行OpenSSH 6.7p1（Debian）客户端是Windows上的FileZilla。
更新：为了响应马丁的信息（请参阅下面的答案），我添加了ping是180ms到190ms之间的服务器和客户端下载相当不变。 此外，CPU使用率非常低，最高为2％到8％。 我尝试了最新版本的winscp 5.73和sftp模式，我用scp模式得到了555kb / s和大约805kb / s的最大值。 而如果我在Filezilla中启动一个辅助并发传输，我也会得到1.3MiB / s的恒定传输。
那么，如果马丁和迈克尔碰触了一下，180毫秒延迟到服务器是math上的限制因素吗？ 还是还有其他的东西可以怪罪我可以提高吞吐量？ 如果没有，我会很感激，如果有人知道任何其他（如lftp，但在Windows上运行良好）的开源下载器是安全的，并支持分段下载。
有三个共同的因素影响传输速度：
带宽 – 一个显而易见的因素，显然不是你的麻烦。
networking延迟/延迟 – SFTP是面向数据包的协议。 下载时，SFTP客户端向SFTP服务器发送“读取”请求，等待响应，将返回的数据附加到本地文件; 并重复，直到文件结束。
即使您的连接速度很快，但如果服务器距离太远（或较慢），数据还是需要一段时间才能恢复。 如果客户这段时间无用地等待，您的传输速度将会很低。
大多数SFTP客户端（包括FileZilla和WinSCP）通过在每个“读取”请求中请求大块文件以及通过发送（排队）多个“读取”请求而不等待对先前的响应来解决该问题。 例如，WinSCP一次最多可以请求32个块，每个32 KB，总共1 MB（这是默认值）。 但是，如果带宽和networking延迟之间存在很大差异，则即使1 MB可能太小而不能饱和带宽。
底层的TCP协议可能会遇到类似的问题。 所以，不仅实际的SFTP客户端是如何有效的，而且还有一个底层的TCP层是如何有效的。
请参阅维基百科上的带宽延迟产品 。
我不认为这也是你的麻烦，至less如果你使用了最新版本的WinSCP进行testing的话。 最近的版本已经有了一些改进 ，使得WinSCP能够像FileZilla一样高效地利用高延迟的连接。
CPU – 被encryption的SFTP是CPU密集型的。 如果CPU速度相对较慢，与较大的带宽相比，传输可能受限于CPU无法encryption（或在下载的情况下解密）数据的速度与networking能够传输的速度一样快。
常见的SFTP客户端不能在CPU内核之间分配encryption/解密，实际上是单CPU内核的容量限制了传输速度。
如果其中一个内核在传输过程中被最大限度利用，请使用Windows任务pipe理器查看。
我也有这个问题。
我使用任务pipe理器将优先级设置为高。
现在我可以达到5 MiB / s
我从Filezilla更改为CuteFTP（得到buckshee副本;））…下载直接到30 + MB！ 我还没有比较这两个设置，因为它迟到了…..