FTPS via GnuTLS slow #1711
Comments
|
Just about everyone of the commands issued to the server takes about 1 second, regardless of complexity or what it may be for:
Let's take this sequence: So now if you look at the same place in the FileZilla log, you will find a clue: "Retrying in 1 seconds" sounds very very fishy. Although FileZilla built the response practically immediately, it seems some configuration error causes it to block for a second. I have no idea why but with this clue, you should be able to find out more. To prove the hypothesis you could activate heavy detailed logging in FluentFTP.GnuTLS - giving the same sort of detail as you see in FileZilla's GnuTLS log, and in the timestamps then you would see that we, the client, don't get the response until about one second has passed. |
|
Thanks for the quick response. I looked into the EAFNOSUPPORT error and it seems that this was a filezilla server configuration issue regarding ipv6. I fixed it and the log However the communication still experiences the 1 second delay. I couldn't find specific information online to one second delays in particular unfortunately. I did try to get more logs by adding The thing that makes me believe that it is not a server misconfiguration is that when I use standard dotnet ssl streams (removing the line Logs of using dotnet ssl streams instead of Gnu tls streamsFluentFtp LogsFile Zilla Server logsLogs with Gnu tls streams against vsftpdFluentFtpLogsvsftpd server logsThanks & any further ideas are much appreciated. |
|
I think I have found out what is happening. The stream read and write methods pause for 1 second on a non-success return code. With detailed logging, we would see the associated error message. Here is how to increase the logging verbosity: client.Config.CustomStream = typeof(GnuTlsStream);
client.Config.CustomStreamConfig = new GnuConfig() {
SetALPNControlConnection = string.Empty,
SetALPNDataConnection = string.Empty,
LogLevel = 1,
LogMessages = GnuMessage.All | GnuMessage.ReadControl | GnuMessage.WriteControl,
};There is definitely something going wrong - funny that is seems to be only on your build. So let's check the error message. It should be of the form: |
|
Please note that I have edited the config code snippet in the previous post after some testing here locally. |
|
Thanks for the code for increasing the log output. I tried with additional logs and it seems your assumption is correct. Before the 1 sec delays occur I can see following errors: Do I understand it correctly that Client sends a CWD and after waiting only 1 ms. Server needs more time though to answer: When it sends I am also very curious why this only happens on my versions. I am using FluentFtp.GnuTLS Version 1.0.31 with FluentFtp Version 52.0.0. How long does GnuTLS usually wait until it sends GNUTLS_E_AGAIN? Can it be configured how many repeats of the error can happen before it blocks? Or can maybe the time inbetween the repeats be configured? Here are the full logs: FluentFtp logsFilezilla-Server logs |
Yes. Absolutely correct. Never seen this happening before, that's why the simplistic approach to this.
It seems logical to assume that this is a timing issue - dependant on client but also especially server time. Due to the nature of what is happening, it only hits us on the control connection, happily not thousands of times on the data connection (there, only 2 times).
I am working on something more automatic. Please stand by, it'l be a new release this evening. |
|
Get Release 1.0.32. It should appear on Nuget any minute from now. Let's see if that gets you up to more speed. I was testing this on my client machine (Core i9 1400k) to one of my FTP Servers in a VM on a Core i9 9900k machine. Rarely ever saw an E_AGAIN. I don't have any SLOW servers currently, such as a Raspberry PI or suchlike. But it is still funny no-one has reported this yet. Total timeout can be configured with config ConnTimeout, by the way (default 15s). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Environment
FTP Server OS: Linux (Ubuntu)
FTP Server Type: FileZilla server
Client Computer OS: Linux (Alpine docker image on Yocto OS)
FluentFTP Version: 52.0.0
Framework: .NET 8
Summary
Hello, we have a problem when using FTPS with FluentFTP. After encountering the same issues as in #1270
we followed the advice and started to use GnuTLS streams. The FTPS connection works and the files are transferred correctly.
However, it is very slow. Transferring a 250KB file takes around 15 seconds overall on the first connection and around 7 seconds on consecutive attempts. It seems that not only the actual file transfer is slow, but also the things done before like the TLS handshake.
When using FTP instead of FTPS the same files usually get transferred in under 0.2 seconds in comparison.
FileZilla Server is configured to require explicit FTP over TLS with a minimum allowed TLS version of 1.3.
Is this a known issue? Or do we maybe have our FtpClient misconfigured?
Thanks in advance for any help.
Regards
FTP Client Configuration
FluentFTP logs
FileZilla Server logs
The text was updated successfully, but these errors were encountered: