为什么当我通过SFTP传输文件，比FTP花费更长的时间？
我手动将一个文件复制到一个服务器，并将其同一个到一个SFTP服务器。 该文件是140MB。
FTP：我有一个11MB /秒的速度
SFTP：我有一个4.5MB / s的速率
我知道文件在发送之前必须encryption。 这是对文件传输的唯一影响吗？ （实际上这不是完全传输时间，而是encryption时间）。
我很惊讶这样的结果。
我是HPN-SSH的作者，我被这里的一位评论者要求称重。我想从一些背景项目开始。 首先，请记住SSHv2是一个多路复用协议，即单个TCP连接上的多个通道。 因此，SSH通道基本上不知道TCP使用的底层stream量控制algorithm。 这意味着SSHv2必须实现自己的stream量控制algorithm。 最常见的实现基本上是重新实现滑动窗口。 这意味着你有SSH滑动窗口骑在TCP滑动窗口顶部。 最终结果是接收缓冲区的有效大小是两个滑动窗口的接收缓冲区的最小值。 股票OpenSSH的最大接收缓冲区大小为2MB，但实际上最终接近1.2MB。 大多数现代操作系统有一个缓冲区，可以增长（使用自动调整接收缓冲区），有效的大小为4MB。 为什么这很重要？ 如果接收缓冲区大小小于带宽延迟乘积（BDP），那么无论系统速度如何，您将永远无法完全填充pipe道。
由于SFTP在TCP和SSHstream量控制上添加了另一层stream量控制，这一点变得更加复杂。 SFTP使用未解决的消息的概念。 每个消息可以是命令，命令的结果或批量数据stream。 未完成的消息可能达到特定的数据报大小。 所以你最终可能会想到另一个接收缓冲区。 这个接收缓冲区的大小是数据报大小*最大未处理的消息（两者都可以在命令行中设置）。 默认值是32k * 64（2MB）。 因此，在使用SFTP时，必须确保TCP接收缓冲区，SSH接收缓冲区和SFTP接收缓冲区的大小都足够大（不要太大，否则在交互式会话中可能会有缓冲问题）。
HPN-SSH直接解决SSH缓冲区问题，最大缓冲区大小约为16MB。 更重要的是，通过轮询TCP连接的缓冲区大小的proc条目（基本上在第3层和第4层之间戳洞），缓冲区dynamic增长到适当的大小。 这可以避免几乎所有情况下的过度缓冲。 在SFTP中，我们将未完成请求的最大数量提高到256个。至less我们应该这样做 – 看起来这个变化没有像预期的那样传播到6.3补丁集（尽pipe它在6.2中，我很快就会修复）。 没有6.4版本，因为6.3 6.4版本（这是6.3版本的1行安全修复）干净地修补。 你可以从sourceforge获得补丁集。
我知道这听起来很奇怪，但正确的缓冲区大小是性能方面最重要的一个变化。 尽pipe许多人认为在大多数情况下，encryption并不是真正糟糕的性能来源。 您可以通过将数据传输到日益远离（RTT）的来源来certificate这一点。 你会注意到RTT越长，吞吐量就越低。 这清楚地表明这是一个RTT依赖的性能问题。
无论如何，随着这个变化，我开始看到了2个数量级的改善。 如果你了解TCP，你就会明白为什么会这么做了。 这不是关于数据报的大小或数据包的数量或类似的东西。 这是完整的，因为为了高效地使用networkingpath，您必须具有与两台主机之间可以传输的数据量相等的接收缓冲区。 这也意味着，如果path不够快，足够长，你可能看不到任何改进。 如果BDP小于1.2MB，HPN-SSH可能对您没有任何价值。
并行化的AES-CTR密码是在多核系统上的性能提升，如果您需要完全encryption端到端。 通常我build议人们（或者控制服务器和客户端）使用NONE密码开关（encryption的身份validation，批量传输数据清晰），因为大多数数据不是那么敏感。 但是，这只适用于像SCP这样的非交互式会话。 它在SFTP中不起作用。
还有一些其他的性能改进，但是没有像缓冲区的正确大小和encryption工作那么重要。 当我获得一些空闲时间时，我可能会通过HMACstream程（目前对性能的最大阻力）进行一些更小的优化工作。
所以如果HPN-SSH太棒了，为什么OpenSSH没有采用它呢？ 这是一个漫长的故事，知道OpenBSD团队的人可能已经知道答案。 我理解他们的许多原因 – 这是一个很大的补丁，需要额外的工作（他们是一个小团队），他们不关心性能和安全性（尽pipeHPN-SSH没有安全性的影响）等等等等。但是，即使OpenSSH不使用Facebook的HPN-SSH。 那么谷歌，雅虎，苹果，史上最大的研究数据中心，美国国家航空航天局，诺阿，政府，军方和大多数金融机构。 在这一点上已经很好的审查了。
如果有人有任何问题随时问，但我可能不会在这个论坛上保持最新。 您可以随时通过HPN-SSH电子邮件地址发送邮件（谷歌）。
更新 ：作为一个评论者指出，我下面概述的问题是固定的这个职位前一段时间。 但是，我知道HP-SSH项目，我要求作者权衡。正如他们解释（最正确的）最有争议的答案，encryption不是问题的根源。 耶的电子邮件和人比我更聪明！
哇，一个只有不正确答案的一年问题。 不过，我必须承认，当我问自己同样的问题时，我认为放缓是由于encryption。 但问问自己下一个合乎逻辑的问题：您的计算机能够多快地encryption和解密数据？ 如果你认为速度接近于OP所报告的4.5Mb /秒（.5625MBs或大约是5.5“软盘容量的一半 ！），你可以自己敲几下，喝一些咖啡，然后问自己同样的问题。
这显然与在数据包大小select中相当于忽略了什么有关 ，或者至less这是LIBSSH2的作者所说的 ，
SFTP的性质及其发送的每个小数据块的ACK，使得在高延迟networking上发送数据时，初始的SFTP实施遭受严重的影响。 如果每个32KB数据必须等待几百毫秒，那么永远不会有快速的SFTP传输。 这种幼稚的实现是libssh2提供的，包括libssh2 1.2.7。
所以速度的打击是由于每个数据包的小包大小x强制ack响应，这显然是疯狂的。
高性能SSH / SCP（HP-SSH）项目提供了一个OpenSSH补丁集，显然可以改善内部缓冲区以及并行encryption。 但是请注意，即使是非并行版本，运行速度仍然高于某些评论者获得的40Mb / s未encryption速度。 修复包括改变OpenSSH调用encryption库的方式，而不是密码，AES128和AES256之间的速度没有差别。 encryption需要一些时间，但它是微不足道的。 它可能在90年代重要，但（就像Java和C的速度），它只是无所谓了。
影响SFTP传输速度的几个因素：
- encryption。 尽pipe对称encryption速度很快，但并没有被忽视。 如果比较快速networking（100mbit或更大）的速度，encryption将成为您的过程的一个中断。
- 哈希计算和检查。
- 缓冲复制。 运行在SSH之上的SFTP使得每个数据块至less被复制6次（每边3次），与普通FTP相比，最好的情况下数据可以传送到networking接口而不被复制。 块复制也需要一些时间。
encryption不仅有cpu，还有一些networking开销。
有各种各样的事情可以做到这一点。 一种可能性是“stream量整形”。 这通常在办公环境中进行，以为业务关键活动预留带宽。 这也可能是由networking托pipe公司，或由您的ISP，由于非常类似的原因。
你也可以在家里简单地设置它。
例如，可能有规则为FTP预留最小带宽，而SFTP可能属于“其他”规则。 或者可能有一个规则为SFTP规定了上限带宽，但其他人也在同一时间使用SFTP。
那么：你从哪里转移文件？
SFTP不是通过SSH的FTP，它是一种不同的协议，与SCP类似，它提供了更多的function 。
为了进行比较，我尝试将运行Raring Ringtail Ubuntu alpha 2 live cd的i5笔记本电脑上的299GB ntfs磁盘映像转移到运行Ubuntu 12.04.1的i7桌面。 报告速度：
通过wifi + powerline：scp：5MB / sec（40 Mbit / sec）
通过千兆位以太网+ netgear G5608 v3：
scp：44MB / sec
sftp：47MB / sec
sftp -C：13MB /秒
因此，在一个好的千兆位连接上，sftp比scp稍微快一点，2010年代的快速CPU看起来足够快encryption，但压缩在所有情况下都不是赢。
然而，在一个不好的千兆以太网链路上，我的sftp远远胜过scp。 有关scp的内容非常琐碎，请参阅2008年comp.security.ssh上的“scp UNBELIEVABLY slow”： https : //groups.google.com/forum/?fromgroups = #!topic/comp.security.ssh/ldPV3msFFQw http： //fixunix.com/ssh/368694-scp-unbelievably-slow.html
你的结果是有道理的。 由于FTP通过非encryption通道运行，它比SFTP（它是SSH版本2协议之上的子系统）更快。 另外请记住SFTP是基于数据包的协议，不同于基于命令的FTP。
SFTP中的每个数据包在被写入到客户端的传出套接字之前被encryption，然后在被服务器接收时被解密。 这当然会导致传输速度慢，但传输非常安全。 使用SFTP等压缩方式（如zlib）可以缩短传输时间，但仍然不会接近纯文本FTP。 也许更好的比较是比较SFTP和FTPS哪一个都使用encryption？
SFTP的速度取决于用于encryption/解密的密码，用于例如zlib的压缩，用于套接字连接的包大小和缓冲区大小。
是的，encryption会给你的CPU增加一些负载，但是如果你的CPU不是古老的，那就不应该像你说的那样影响。
如果启用SSH压缩，SCP实际上比FTP更快（如果我记得，对于我尝试的文件来说FTP的速度是FTP的两倍）。 我没有真正使用SFTP，但我相信它使用SCP进行实际的文件传输。 所以请试试这个，让我们知道:-)
