39

How do FTP, FTPS, SFTP, and SCP compare in terms of transfer rate and how can I compare them through testing?

Graham
  • 399
  • 1
  • 3
  • 3
  • 3
    Speed isn't the important difference between FTP and the others. – ceejayoz Dec 09 '13 at 16:25
  • 8
    I'm not sure why this was voted off-topic. It is certainly very relevant to my work as a professional sysadmin - why weren't file transfers using anywhere near the bandwidth of the entire connection path? – Dan Pritts Apr 28 '17 at 14:46
  • You can compensate for the speed difference of SFTP by using multiple TCP connections driven by [LFTP and the mirror subsystem using SFTP](https://serverfault.com/questions/843691/speed-up-sftp-uploads-on-high-latency-network/843714#843714) without sacrificing security. It can even use multiple threads for one single large file. – Aaron Apr 28 '17 at 16:20

4 Answers4

39

If you have a fast wide-area network you will find that sftp and scp are about the same speed, which is slow. They both suffer from performance problems in the underlying openssh. With modern hardware, this is not due to encryption overhead, but rather due to problems with the openssh implementation - it implements its own internal windowing mechanism which breaks down on fast connections.

These problems become more obvious on long-distance (higher latency) connections, but I've experienced slowness even on LANs.

These are well-documented, and patches are available to fix the problem. Patching either end of the connection can help; ideally you'd patch both ends. For more info and the patches, see High Performance SSH at Pittsburgh Supercomputer Center.

BTW, encryption overhead can become an issue too, once the windowing problem is solved. The patches have fixes for that too.

Meanwhile, you will find that ftp is woefully insecure; it sends passwords in plain-text.

ftps I think wraps the ftp protocol in SSL. it's probably faster than unpatched SFTP/SCP.

One final note: in my experience, the WinSCP client is (at least sometimes) painfully slow. I don't know why, but based on their FAQ I'm not the only person who's had this problem. So if you're scp'ing from Windows, and it seems slow, try a different client. Even with an unpatched openssh server, you can do much, much better with a different client. I'm not sure which are good clients, unfortunately, other than presumably plain pscp from Putty.

Dan Pritts
  • 3,181
  • 25
  • 27
  • 1
    Finally. Someone who knows what they are talking about. Yes, FTPS is basically FTP in the SSL. SFTP/SCP will always be slower then when using FTP – Jason Dec 18 '13 at 17:42
  • Do you have any idea why I get 300 kb/s with scp while getting around 10 Mb/s (nearly max speed) with sftp? That doesn't seem to be "about the same speed". This is over 100Mbps ethernet. – graywolf Mar 21 '16 at 22:17
  • Best guess, your scp is a flawed implementation (e.g. WinSCP), but your sftp isn't. Even if they are in the same GUI wrapper, they might be different on the inside. – Dan Pritts Jul 20 '16 at 18:43
  • Dan, any idea why this SSH Patch isn't applied to the main OpenSSH? Clearly it's 1~2 orders of magnitude better (>10x even on a 100Mbps LAN) so why isn't this the new OpenSSH standard? How can we make it so? – Gabriel Staples Aug 27 '17 at 03:47
  • My understanding is that PSC submitted the patches to the openbsd folks (who write openssh). They were not interested. I heard vague statements that none of the openbsd people had high-bandwidth connections and they didn't notice any issues, and/or necessarily believe there was a real problem. This was several years ago, and is hearsay, so I can't vouch for its accuracy. – Dan Pritts Sep 05 '17 at 20:02
  • I just tried HPN-SSH (installed on both ends) and it didn't help at all. scp/rsync transfers are still 3mbps while the same file over http is 100mbps. – bparker Mar 30 '18 at 04:04
  • are you perhaps on really low-powered hardware? Raspberry Pi or something? – Dan Pritts Apr 02 '18 at 15:22
  • Nope @DanPritts, both machines are Core i7 with plenty of RAM and fast disks, about 60ms apart from each other network wise. – bparker Jun 19 '18 at 01:30
  • best guess is that you aren't really running the HPN version on one end or the other. Which isn't much help, I know, but if you haven't double checked, you should. – Dan Pritts Jun 20 '18 at 02:17
  • As of 2020, is HPN-SSH included in OpenSSH at this point, or is it still something that needs to be separately installed? – FireController1847 Nov 20 '20 at 06:17
  • See https://github.com/rapier1/openssh-portable/blob/master/HPN-README. The repo shows changes 27 days ago, so I expect the answer is that you still need to use it. It's possible they have incorporated some, but not all, of the HPN changes in mainline. I haven't been using it for a while since my performance needs are modest in my current situation so I'm not up on the details. You should also check with your distribution, which may have installed the patches for you. – Dan Pritts Nov 30 '20 at 17:30
6

In general all of the protocols will perform about the same. You are more likely to be limited by the speed of your network or disk than by the protocol.

Older versions of OpenSSH (SFTP/SCP) used a fixed window size that will limit the speed over high latency networks (say trans-atlantic). There is a patch set to fix this problem called HPN (High performance networking) and it is included in most modern installs of OpenSSH.

If you are running in to a situation such as a gigabit or faster LAN link and a slower CPU then SFTP/SCP may run into a bottleneck. You'll be able to tell because the ssh/scp/sftp process will be using 100% of cpu on the sending or receiving hosting. If you are using a newer version of OpenSSH (6.4+) you can enable a threaded version of the AES cipher that will be able to use more than 1 core to handle the encryption and will be less likely to be limited by CPU rather than disk or network bandwidth.

If you control both the sending and receiving side, OpenSSH 6+ also has an optional 'NONECIPHER' mode. This uses the regular encryption/keys etc to login to the remote machine, but then drops to an unencrypted connection for the actual file copying. This will remove that CPU overhead. There are safeguards built in to the NONECIPHER than prevent you from getting a shell that is not encrypted.

In the end the protocol should not be the limitation on speed, although older versions of ssh do have trouble with high latency links.

Allan Jude
  • 1,226
  • 9
  • 12
  • Good to know that the defaults are now to have the patches installed, although it looks like redhat has explicitly decided against it (https://access.redhat.com/site/solutions/53215). Also, Note that trans-atlantic latency isn't really all that much. Current ping rtts: umich -> stanford (california): 89ms. umich -> cambridge (uk) : 134ms. Also, isn't the combination of latency and bandwidth that causes the issue? so lower latency but higher bandwidth links can still have problems. – Dan Pritts Dec 18 '13 at 18:45
3

Based on encryption overhead, I'd say that plain FTP probably has slightly better performance than the other protocols, but it's probably negligible. I'd use the protocol that provides the security you need first, then worry about throughput.

That being said, you'll have to set up a test to find the real numbers. Everything above is just my opinion. If you're testing performance locally, set up a server on your network. If the end use will be over the internet, test from an external host.

Jim G.
  • 2,607
  • 1
  • 18
  • 19
  • 2
    The performance overhead is orders of magnitudes, not slight. Closer to 10x than 2x slower. I was surprised myself. – Gomibushi Jun 11 '16 at 17:14
1

As always, google holds the answers,
FTP v/s SFTP v/s FTPS
Which says FTP > FTPS > SFTP
FTP also appears to be faster than SCP in someone else's test(http://www.lysesoft.com/support/forums/viewtopic.php?f=5&t=542) but I'd recommend trying it for yourself to see.
So just set up SCP and FTP on any random box on your network, then run a typical file transfer and see how long it takes on both

Community
  • 1
  • why do you say FTP is an internet protocol and SCP for the LAN? – Dan Pritts Dec 05 '13 at 20:04
  • 6
    Ah, I see you got that from the linked eHow article. eHow is wrong. Both protocols were designed for Internet usage. The article has several other errors; the writer clearly doesn't know what he/she is talking about. – Dan Pritts Dec 05 '13 at 20:14
  • Now that I think about it, you're right, I probably should have checked. –  Dec 06 '13 at 15:08
  • 1
    Sites like eHow never know what they are talking about. – Jason Dec 18 '13 at 17:40