为什么当我通过SFTP传输文件时,它需要比FTP更长的时间？

Question

我手动将文件复制到服务器,将相同的文件复制到SFTP服务器.该文件是140MB.

FTP:我的速率为11MB/s

SFTP:我的速率为4.5MB/s

我知道文件必须在发送之前加密.这是对文件传输的唯一影响吗？(实际上这不是转移时间,而是加密时间).

我对这样的结果感到惊讶.

Answer 1

我是HPN-SSH的作者,我在这里被一位评论者要求权衡.我想从几个背景项开始.首先,重要的是要记住SSHv2是一种多路复用协议 - 通过单个TCP连接的多个通道.因此,SSH通道基本上不知道TCP使用的基础流控制算法.这意味着SSHv2必须实现自己的流量控制算法.最常见的实现基本上是重新实现滑动窗口.这意味着您将SSH滑动窗口置于TCP滑动窗口的顶部.最终结果是接收缓冲区的有效大小是两个滑动窗口的接收缓冲区的最小值.股票OpenSSH的最大接收缓冲区大小为2MB,但实际上最终接近~1.2MB.大多数现代操作系统都有一个可以增长的缓冲区(使用自动调整接收缓冲区),最大有效大小为4MB.为什么这很重要？如果接收缓冲区大小小于带宽延迟乘积(BDP),那么无论系统速度有多快,您都无法完全填充管道.

由于SFTP在TCP和SSH流控制上添加了另一层流控制,因此这很复杂.SFTP使用未完成消息的概念.每条消息可以是命令,命令的结果或批量数据流.未完成的消息可以达到特定的数据报大小.所以你最终得到了你可能想到的另一个接收缓冲区.此接收缓冲区的大小是数据报大小*最大未完成消息(两者都可以在命令行上设置).默认值为32k*64(2MB).因此,在使用SFTP时,您必须确保TCP接收缓冲区,SSH接收缓冲区和SFTP接收缓冲区都具有足够的大小(不会太大或者您可以在交互式会话中遇到过度缓冲问题).

HPN-SSH通过最大缓冲区大小约16MB直接解决SSH缓冲区问题.更重要的是,通过轮询TCP连接的缓冲区大小的proc条目(基本上在第3层和第4层之间挖洞),缓冲区动态增长到适当的大小.这避免了几乎所有情况下的过度缓冲.在SFTP中,我们将未完成的请求的最大数量提高到256.至少我们应该这样做 - 看起来这个更改没有按预期传播到6.3补丁集(尽管它在6.2中.我会尽快修复).没有6.4版本,因为6.4补丁干净地对6.4(这是6.3的1行安全修复).您可以从sourceforge获取补丁集.

我知道这听起来很奇怪,但正确调整缓冲区是性能方面最重要的变化.尽管许多人认为加密并不是大多数情况下性能不佳的真正根源.您可以通过将数据传输到越来越远的源(就RTT而言)来证明这一点.您会注意到RTT越长,吞吐量越低.这清楚地表明这是一个依赖于RTT的性能问题.

无论如何,随着这种变化,我开始看到最多2个数量级的改进.如果您了解TCP,您就会明白为什么会产生这样的差异.它不是关于数据报的大小或数据包的数量或类似的东西.这是完整的,因为为了有效利用网络路径,您必须具有等于​​两个主机之间可以传输的数据量的接收缓冲区.这也意味着如果路径不够快且足够长,您可能看不到任何改进.如果BDP小于1.2MB HPN-SSH对您没有任何价值.

如果您需要端到端的完全加密,并行化的AES-CTR密码可以提高具有多个内核的系统的性能.通常我建议人们(或控制服务器和客户端)使用NONE密码交换机(加密身份验证,明文传递的批量数据),因为大多数数据都不是那么敏感.但是,这仅适用于像SCP这样的非交互式会话.它在SFTP中不起作用.

还有一些其他的性能改进,但没有什么比正确调整缓冲区和加密工作的重要性.当我获得一些空闲时间时,我可能会管理HMAC流程(目前对性能的最大拖累)并进行一些小的优化工作.

那么,如果HPN-SSH太棒了,为什么OpenSSH没有采用它呢？这是一个很长的故事,知道OpenBSD团队的人可能已经知道了答案.我理解他们的许多原因 - 这是一个很大的补丁,需要额外的工作(他们是一个小团队),他们并不关心性能和安全性(尽管对HPN-SSH没有安全隐患) )等等.但是,尽管OpenSSH不使用HPN-SSH Facebook.谷歌,雅虎,苹果,大多数大型研究数据中心,NASA,NOAA,政府,军队和大多数金融机构也是如此.在这一点上经过了很好的审查.

如果有任何人有任何问题随时可以问,但我可能不会在这个论坛上保持最新.您可以随时通过HPN-SSH电子邮件地址向我发送邮件(谷歌).

Answer 2

更新:正如一位评论者指出的那样,我在下面列出的问题在本文之前的某个时间得到了解决.但是,我知道HP-SSH项目并且我要求作者权衡.正如他们在(最正确的)最受欢迎的答案中解释的那样,加密不是问题的根源.是的电子邮件和人比我聪明!

哇,这个一年之久的问题只有不正确的答案.但是,我必须承认,当我问自己同样的问题时,我认为减速是由于加密造成的.但问问自己下一个合乎逻辑的问题:您的计算机加密和解密数据的速度有多快？如果您认为该速率接近OP报告的4.5Mb /秒(.5625MBs或大约是5.5"软盘容量的一半!)自己砸几次,喝点咖啡,再问自己同样的问题.

这显然与数据包大小选择中的疏忽有关,或者至少是LIBSSH2的作者所说的,

SFTP的性质及其发送的每个小数据块的ACK,使得初始的简单SFTP实现在高延迟网络上发送数据时受到严重影响.如果你必须等待几百毫秒的每32KB数据,那么永远不会有快速的SFTP传输.这种天真的实现是libssh2提供的,直到并包括libssh2 1.2.7.

因此速度命中是由于每个数据包的小数据包大小x强制性ack响应,这显然是疯了.

该高性能SSH/SCP(HP-SSH)项目提供了一个OpenSSH的补丁集,这显然提高了内部缓存以及并行加密.但请注意,即使是非并行版本的速度也超过了某些评论者获得的40Mb/s未加密速度.该修复涉及改变OpenSSH调用加密库的方式,而不是密码,AES128和AES256之间的速度没有差别.加密需要一些时间,但它很少.它可能在90年代重要但是(就像Java与C的速度一样)它不再重要了.

Answer 3

有几个因素会影响SFTP转移的速度:

1. 加密.尽管对称加密速度很快,但并不是那么快就被忽视了.如果您在快速网络(100mbit或更大)上比较速度,加密将成为您的过程的中断.
2. 散列计算和检查.
3. 缓冲区复制.运行在SSH之上的SFTP导致每个数据块至少复制6次(每侧3次),与普通FTP相比,在最佳情况下,数据可以传递到网络接口而不会被复制.块复制也需要一些时间.

Answer 4

加密不仅有cpu，还有一些网络开销。