0

Question

  • iperf3 reports 942Mbps
  • SFTP 1GB transfer at 94~100 MB/s
  • Explicit FTPS 1GB transfer at 19~23 MB/s
  • Both CPU / IO load is under 20% on htop

For nearly 99% posts I find in google says that FTP - regardless of encrypted or not - will always be faster than SFTP, and I also find it reasonable.

I spent multiple days over last few years configuring and scratching head why FTPS isn't using full bandwidth, and eventually tried SFTP. Then found out that this was 4x times the speed utilizing nearly full bandwidth.

Is there any possible explanation or vsftpd config error that made FTPS slower than SFTP?

--

To clarify the intention again, I am totally fine using SFTP from now on. I'm exhausted and out of time to fiddle more with FTPS. SFTP works flawlessly for me so I'm not trying to use FTPS again.

I am just curious that there must be reason why majority of tutorials and posts out there says FTPS is faster than SFTP, yet we're seeing exact opposite here.

Configuration

Skipping detailed Server/Client HW info, as iperf3 & SFTP already proved that this isn't Server/Client performance issue.

  • 1 Home Router with 2Gbit/s HW NAT

    • iptime a2003ns-mu (Uses RTL8197F)

  • vsftpd server behind router with 1G link speed

    • Debian 12.2.0-14
    • ASRock J4105m
    • vsftpd 3.0.3

  • client PC behind router at 1G link speed

    • Win11 Edu
    • FileZilla 3.66.4

  • Uses TLSv1.2 on FTP for outside connection

Situation

  • Accessing FTP server's files from local network

vsftpd config

# General
pam_service_name=vsftpd
utf8_filesystem=YES
dirmessage_enable=YES
xferlog_enable=YES

Connectivity


listen=YES
listen_ipv6=NO
connect_from_port_20=YES


Security


anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022


chroot


chroot_local_user=YES
secure_chroot_dir=/var/run/vsftpd/empty
allow_writeable_chroot=YES


Certs


rsa_cert_file=/etc/letsencrypt/live/[REDACTED]/fullchain.pem
rsa_private_key_file=/etc/letsencrypt/live/[REDACTED]/privkey.pem


Explicit SSL


ssl_enable=YES
force_local_logins_ssl=YES
force_local_data_ssl=YES
allow_anon_ssl=NO
require_ssl_reuse=NO
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
ssl_ciphers=HIGH


Passive mode


pasv_addr_resolve=YES
pasv_address=[REDACTED].com
pasv_enable=YES
pasv_min_port=12000
pasv_max_port=13000


Preventing error using local address connection


pasv_promiscuous=yes

Speed data

[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   113 MBytes   950 Mbits/sec    0    218 KBytes
[  5]   1.00-2.00   sec   112 MBytes   942 Mbits/sec    0    218 KBytes
[  5]   2.00-3.00   sec   112 MBytes   938 Mbits/sec    0    218 KBytes
[  5]   3.00-4.00   sec   112 MBytes   942 Mbits/sec    0    218 KBytes
[  5]   4.00-5.00   sec   112 MBytes   942 Mbits/sec    0    218 KBytes
[  5]   5.00-6.00   sec   112 MBytes   941 Mbits/sec    0    218 KBytes
[  5]   6.00-7.00   sec   113 MBytes   944 Mbits/sec    0    218 KBytes
[  5]   7.00-8.00   sec   112 MBytes   940 Mbits/sec    0    218 KBytes
[  5]   8.00-9.00   sec   112 MBytes   942 Mbits/sec    0    218 KBytes
[  5]   9.00-10.00  sec   112 MBytes   942 Mbits/sec    0    218 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.10 GBytes   942 Mbits/sec    0             sender
[  5]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec                  receiver

jupiterbjy
  • 113
  • 5
  • ssl_ciphers=HIGH try other settings here. Using HIGH settings is a bottleneck. – paladin Jan 30 '24 at 17:58
  • @paladin I found that others can use LOW or NORMAL but both aren't available for me. Nor many config QnA or tutorial out there shows anything other than HIGH. I'll try DES-CBC3-SHA which according to man should be default and measure again – jupiterbjy Jan 30 '24 at 18:02
  • status=2/INVALIDARGUMENT for DES-CBC3-SHA / LOW / NORMAL. Is there any other recommended cipher method? This also is a bit confusing as CPU is just idling at 30% Load now while transit, no core at 100% so seems like this isn't too much for it.. unless if there's hw encryption or something similar – jupiterbjy Jan 30 '24 at 18:04
  • Try another FTPS client. – AlexD Jan 30 '24 at 18:15
  • @AlexD WinSCP reports same results, filezilla isn't the issue I think – jupiterbjy Jan 30 '24 at 18:26
  • You may also try to use another FTP server: ProFTPD might be a choice for you, but it's a bit difficult to configure, as it's providing a lot of options. – paladin Jan 30 '24 at 18:26
  • I would also look into the network traffic with tcpdump for packet sizes, delays, losses, and TCP window size. – AlexD Jan 30 '24 at 18:27
  • @paladin thanks for suggestion, but I saw so many issue regarding setting that up correctly I gave up long ago haha! Btw just to clear up my intention again, I'm not trying to fix this slow FTPS - I am just curious gap between majority saying FTPS is faster yet why SFTP can be faster. – jupiterbjy Jan 30 '24 at 18:28
  • PS I also cannot believe that using a setting for ssl_ciphers=HIGH would result in using DES-CBC3-SHA ciphers, as those are not really high in terms of security at current standards. Maybe your FTPS server has a bug and uses another cipher suite than stated. You can check the used cipher suite using openssl: openssl s_client -connect example.com:port – paladin Jan 30 '24 at 18:32
  • @paladin as I mentioned I am just trying default value if that improves, as it should be more easier on CPU (despite CPU is idling) then can prove that if it's cipher algorithm issue or not. Yet for my vsftpd seems like that isn't even case as it sees that as invalid value – jupiterbjy Jan 30 '24 at 18:41
  • Some encryption methods are run with specific hardware acceleration. Those hardware accelerators are the prefered choice as processing unit. Some of those accelerators may be not fast enough. But usually, these are corner cases. You usually want to use AES for transport encryption, as it's fast and mostly secure for these cases. Most modern computers also support hardware encryption/decrytpion of AES. PS you should read about encryption in general, to have a greater view – paladin Jan 30 '24 at 18:47
  • @paladin j4105 do has AES-NI instruction for HW encryption, sadly I have absolutely no idea on it's capability. But seeing that SFTP speed is fine encrypting whole SSH tunnel - is it safe to say the HW is capable? And, thanks for suggestion - I did study very shallow level of encryption like history, etc for certification but this issue is something beyond my understanding, and sadly no one's willing to explain the question itself but wants me to fix FTPS.. haha – jupiterbjy Jan 30 '24 at 19:16
  • did you try a regular FTP (no TLS) to see if at least the non-encrypted one is faster than sftp (it should) ? if not, you have another issue in the FTP server config (switching to glFTPd is a good option) – olivierg Jan 30 '24 at 20:24
  • @paladin could give a source that encryption uses floating point calculations? – AlexD Jan 30 '24 at 20:25
  • Oh, you are right, I'm sorry, it's the other way @AlexD Thanks, I've deleted my wrong comment. (I naively thought that using elliptic curves would need a FPU) – paladin Jan 30 '24 at 20:32
  • I would guess your FTPS server is just buggy or is using a cipher suite which needs a lot of processing power. CPU have different kinds of proecessing units, some are more destined to be used than others for certain tasks. If you want to know more, read about how CPU works in general. – paladin Jan 30 '24 at 20:33
  • @olivierg you're correct, how dumb of me to not test that out - it is slightly faster at 24MB/s but overall already far behind. Considering this already is clean reinstall of debian and previously was same on lubuntu, maybe there's some compatibility issue with this hardware and vsftpd – jupiterbjy Jan 31 '24 at 05:09
  • @paladin yeah seems like buggy one was issue, I can't fix this (literally installed vsftpd first after fresh reinstall) so maybe I should rather replace entire mainboard + cpu. About different processing units, even during lectures I never was taught more than generic stuffs like TLB, pipelining and etc. Is there any recommended book that also covers like HW decoder and such? – jupiterbjy Jan 31 '24 at 05:18
  • I have tested your vsfptd config in my lab and got 100-110 MB/sec on 1 GB network. – AlexD Jan 31 '24 at 14:37
  • @AlexD Thanks for testing, I'm now very sure this is not configuration issue at least! – jupiterbjy Feb 01 '24 at 03:01
  • Could you run two following commands on the server openssl speed -elapsed -aead -evp aes-256-gcm and openssl speed -elapsed -aead -evp ChaCha20-Poly1305? – AlexD Feb 01 '24 at 08:22
  • Also, could you verify which ciphers are actually used if Filezilla logs show this information? – AlexD Feb 01 '24 at 09:37
  • @AlexD filezilla shows regardless without =HIGH or not: TLS1.3, Cipher: AES-256-GCM - for encryption benchmark here's pastebin link. Considering perf is same without encryption, yet this is fresh install, I wonder if vsftpd has compatibility issue with HW or router's issue, kinda mysterious. – jupiterbjy Feb 02 '24 at 10:13
  • I suspected that you don't have HW-accelerated AES but the openssl speed result doesn't confirm it, you still have AES twice as fast compared to ChaCha used by SFTP by default and more than enough to handle 100 MB/sec. Without AES-NI HW acceleration ChaCha is about 3-5 times faster than AES so it would be consistent with the speed difference between SFTP and FTPS if your system is limited by CPU. You can check if vsftpd is limited by CPU - its working process should consume one CPU core entirely and show 100% CPU usage in top. There are usually two vsftpd processes during transfer. – AlexD Feb 02 '24 at 10:50
  • @AlexD Non of CPU core's load is >30%. but as indicated in prev. comment: I stupidly didn't test vsftpd without encryption! Even without encryption, FTP is still same at ~24MB/s, all cores just idling, so I now is theorizing something else is preventing vsftpd to use full HW capability. Since SFTP showed that network / client is not an issue, and with server's HW just idling, I'm completely lost. – jupiterbjy Feb 03 '24 at 05:42
  • 1
    You can go deep and try to profile the performance of the vsftpd with perf, check the network traffic for delays or retransmissions with tcpdump or try another FTP server implementation. – AlexD Feb 03 '24 at 07:10

1 Answers1

0

SFTP operates over a single, secure connection. It uses a secure channel (SSH) for both data and control information. This eliminates the need for separate data and control connections as in FTPS, which can result in reduced latency. FTPS, on the other hand, typically uses two separate channels for control (command) and data, which may introduce additional overhead.

SFTP relies on the SSH protocol, which provides strong encryption by default. The encryption algorithms used in SFTP are generally efficient and optimized for secure file transfers. FTPS, on the other hand, may use various encryption options, and the choice of encryption algorithms can impact performance. In some cases, less efficient algorithms might be chosen, slowing down data transfer speeds.

Try to increase the passive port range

pasv_min_port=12000
pasv_max_port=13000

Modify the ssl_ciphers to include more secure and performant cipher suites:

ssl_ciphers=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384
Turdie
  • 2,564
  • 1
    Imo, the argument in your first paragraph is actually incorrect. Implementing SFTP efficiently is actually not a trivial task. See also https://serverfault.com/q/694062/168875 – Martin Prikryl Jan 30 '24 at 17:21
  • Yes you can mess up everything. But in mu experience with Debian/Ubuntu based systems and also Centos, when you install the ssh package, you can quite easily use sftp – Turdie Jan 30 '24 at 17:23
  • That's logical because there is no encryption used in FTP. – Turdie Jan 30 '24 at 17:48
  • So, the use of two channels for FTPS explains 5 times difference in throughput? – AlexD Jan 30 '24 at 17:49
  • I could be a reason. FTPS just has more protocol overhead than SFTP has – Turdie Jan 30 '24 at 17:50
  • Ah mybad, I made question a bit more clear - I was very disoriented why majority of tutorials & posts out there says FTPS is faster than SFTP, yet actual result for me differ vastly - Would really appreciate if you also added why such discrepancy exists too! – jupiterbjy Jan 30 '24 at 17:50
  • Have you tried doing any measurements? – AlexD Jan 30 '24 at 17:51
  • You could try to increase the passive port range to allow more concurrent connections pasv_min_port=12000 pasv_max_port=13000 – Turdie Jan 30 '24 at 18:03
  • Increased ports and set cipher methods, port-forward again, same speed as before sadly – jupiterbjy Jan 30 '24 at 18:17
  • Iperf is not the ideal tool, in this case i would test this way lftp -u <username>,<password> -e "pget -n 5 ftps://<hostname>/<remote_file>; bye" ftps://<hostname> – Turdie Jan 30 '24 at 18:20
  • I added iperf merely to prove that my networks are not the issue, SFTP double confirmed that by sustaining near 100MB/s bandwidth. – jupiterbjy Jan 30 '24 at 18:38
  • Seems like core issue was something very specific to j4105m, but I got explanation of how potentially SFTP could be faster which is my intention - I'll mark this as an answer! – jupiterbjy Jan 31 '24 at 05:22