Sending and receiving data over an SSL channel is slower for two reasons:
- The amount of raw data sent is increased because SSL uses a record layer, where the encrypted data is encapsulated in records. The overhead of the record structures, plus the expansion due to padding of the underlying encryption algorithm, contribute to an increase in the amount of data sent.
- Processing must occur both on the client and server side to encrypt/decrypt.
I wanted to perform some experiments to compare the performance of SSL and non-SSL FTP downloads. I tested on a computer connected to the Internet via a cable modem communicating with a FileZilla FTP server at ftp.secureftp-test.com (which is an FTP server available for testing FTPS using a "test" account). I downloaded a 37MB file using Chilkat FTP2 in SSL and non-SSL modes. I also downloaded the same using WS_FTP in SSL and non-SSL modes. Here are the performance results:
Chilkat FTP2 in VB.NET application, no SSL: 133 KB/sec
WS_FTP, no SSL: 129 KB/sec
Chilkat FTP2 in VB.NET application, with SSL: 67 KB/sec
WS_FTP, with SSL: 72 KB/sec
A few notes: the performance varies according to the loads present on client and server at the time of testing. In general, Chilkat performed virtually the same as WS_FTP. During the SSL downloads I noticed pauses during the transfer, both with FTP2 and WS_FTP. It’s important that the FTP2’s IdleTimeoutMs property not be set too low, otherwise a pause could cause the transfer to timeout.
One more note: My recommendation for transferring very large files securely is to zip the files on the server using strong (AES) encryption and then FTP the encrypted zip over a non-SSL channel. The total amount of data sent will be less, and the transfer rate will be almost twice that of using SSL.
