htf*_*ree 6 ssh rsync sftp scp winscp
我正在从服务器下载，使用 FileZilla 的下载速度最高为 1.3MiB/秒，但我可以开始并发下载，它们也将以 1.3MiB/秒的速度下载。那么为什么我不能以超过 1.3MB/s 的速度仅下载一个文件并接近饱和可用带宽（~6+MB/s）？
我知道我可以使用其他一些支持分段下载的 SFTP 客户端，例如 lftp，知道其他开源的好客户端吗？
但我仍然想知道是什么限制了一个文件的下载速度为 1.3MB/s，是 TCP 和缓冲区等的一些技术限制还是一些配置问题？我检查并确定根本没有为 FileZilla 启用流量限制。
我也试过 rsync，它比 FileZilla/SFTP 更糟糕。我也尝试过 WinSCP，无论使用哪种 SCP/SFTP 方法，它都是最慢的。因此，与其他传输方法相比，FileZilla 以 1.3MB/s 的恒定传输速度相当不错。
如果有人对为什么传输峰值为 1.3MB/s 有很好的解释，我真的很想知道，以及是否可以在不诉诸分段下载的情况下增加这一点。服务器正在运行 OpenSSH 6.7p1 (Debian) 客户端是 Windows 上的 FileZilla。
更新：为了响应 Martin 的信息（见下面他的回答），我补充说服务器和正在下载的客户端之间的 ping 是 180 毫秒到 190 毫秒。此外，cpu 使用率非常低，最多 2% 到 8%。我尝试了最新版本的 winscp 5.73 和 sftp 模式，我得到了 555kb/s 和大约 805kb/s 最大的 scp 模式。而如果我在 Filezilla 中启动辅助并发传输，我也会得到恒定的 1.3MiB/s。
那么，正如 Martin 和 Michael 所提到的，服务器的 180 毫秒延迟是否会成为数学上的限制因素？或者还有什么可以归咎于我可以提高吞吐量？如果没有，如果有人知道任何其他（如 lftp 但在 Windows 上运行良好）开源下载器，它是安全的并支持分段下载，我将不胜感激。
Mar*_*ryl 12
影响传输速度的常见因素有以下三个：
带宽——一个明显的因素，显然不是你的麻烦。
网络延迟/延迟– SFTP 是面向数据包的协议。下载时，SFTP客户端向SFTP服务器发送“读”请求，等待响应，将返回的数据追加到本地文件中；并重复，直到文件结束。
即使您的连接速度很快，如果服务器距离较远（或速度较慢），数据返回也需要一些时间。如果客户端将这段时间浪费在无用的等待上，您的传输速度会很慢。
大多数 SFTP 客户端（包括 FileZilla 和 WinSCP）通过在每个单个“读取”请求中请求大块文件以及发送（排队）多个“读取”请求而不等待对前一个的响应来解决该问题。例如，WinSCP 一次最多可以请求 32 个块，每个块 32 KB，总计 1 MB（这些是默认值）。但是，如果带宽和网络延迟之间存在很大差异，即使是 1 MB 也可能太小而无法使带宽饱和。
底层 TCP 协议可能会遇到类似的问题。因此，这不仅是实际 SFTP 客户端的效率如何，还有底层 TCP 层的效率如何。
另请参阅维基百科上的带宽延迟产品。
我也不认为这是您的问题，至少如果您使用最新版本的 WinSCP 进行测试。最近的版本有一些改进，允许 WinSCP 像 FileZilla 一样有效地利用高延迟连接。
CPU – 被加密的 SFTP 是 CPU 密集型的。如果您的 CPU 速度相对较慢，与大带宽相比，传输可能会因您的 CPU 无法以您的网络能够传输数据的速度加密（或在下载时解密）数据而受到限制。
常见的SFTP客户端无法在CPU核之间分配加密/解密，因此限制传输速度的实际上是单个CPU核的容量。
使用 Windows 任务管理器查看在传输过程中是否最大限度地利用了其中一个核心。
这个答案的一部分来自 WinSCP 文章文件传输速度非常低。WinSCP 不会利用所有可用带宽。如何提高传输速度？