FTP、FTPS、SFTP、SCP在传输速率上如何比较，如何通过测试进行比较？
我正在从服务器下载，使用 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 上运行良好）开源下载器，它是安全的并支持分段下载，我将不胜感激。
我们有一些同步脚本，用于客户端使用 scp 将文件发送到由其提供商之一管理的远程服务器。最近他们关闭了它，他们提供的新的不允许scp，只允许sftp（无法在远程服务器上获取shell，因此scp / rsync无法运行）。
有没有一种简单的方法可以用 sftp 替换脚本中的 scp ？我想我所知道的最简单的方法是使用 sshfs 并使用 cp 而不是 scp，但这非常难看。
看起来 sftp 可以使用 -b 传递一个包含命令的文件，但这意味着重新编码部分脚本。我想知道是否有任何方法可以使用 sftp 作为 scp 的替代品，或者其他一些可以提供类似功能的软件包？（即 sftp /source user@remote:/dest 或类似的东西，如果我能 sed 脚本只替换命令就完美了）
谢谢