FTP/FTPS/SFTP/SCP - Speed comparison [closed]

Solution 1:

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.

Solution 2:

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.

Solution 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.