2

I have a .NET Core microservice (API) that is a apart of an Azure Service Fabric application. The Service Fabric consists of 3 nodes. I have made the service run both on HTTP and HTTPS with a valid certificate. The problem is in the performance difference between the HTTP and HTTPS connections.

I am using a Let's Encrypt certificate. (I have also tried other free trial SSL certificates just to see if it makes a difference.) I am exposing the endpoints with Kestrel, defining them in the Service Fabric ServiceManifest and ApplicationManifest, and opening the ports via Azure Load Balancer. This is how I setup the endpoints using Kestrel:

.UseKestrel(options =>
{
    options.Listen(IPAddress.IPv6Any, 80);
    options.Listen(IPAddress.IPv6Any, 443, listenOptions =>
    {
        listenOptions.UseHttps("ssl.pfx", "password");
        listenOptions.NoDelay = true;
     });
})

When I hit the endpoint of my API from HTTP, the response time is consistently 0.06-0.2sec. However, when I hit it from HTTPS, it is not consistent and a lot slower (generally 10-30 times); the response time bounces from 0.5 (rarely) - 3-4 seconds. This inconsistency is unacceptable. My suspicion is that the TLS handshake is taking very long. Unfortunately, I have no idea why.

EDIT: The previously linked duplicate question explains the general behavior for HTTPS and I knew that before. However, my case is specific to the described environment, so the given answer doesn't fully satisfy my question. I have a running .NET web app using HTTPS on Azure that hasn't got this huge performance difference.

Rob
  • 45,296
  • 24
  • 122
  • 150
Jonas Petraška
  • 130
  • 1
  • 9
  • 2
    Connecting via SSL/TLS requires the handshake, which includes several roundtrips and cryptographic operations. However, unlike HTTP (which is session-less), an SLL connection can be used over and over. You do the handshake, establish a session and then talk away. You should only have to pay for the handshake once. – Flydog57 Feb 07 '19 at 22:36
  • 2
    Are you using an HTTPS proxy? Those are [notoriously slow](https://support.microsoft.com/en-ca/help/315810/browser-is-slow-to-respond-when-you-use-an-automatic-configuration-scr). If you are not, you can speed up HTTPS substantially by setting your HTTPS `request.Proxy = null`. – Dour High Arch Feb 07 '19 at 22:41
  • @Flydog57 I'm aware that HTTPS is keeping track ot the session. Could it be the case, that for some reason the session expires sooner that it's supposed to ? Because, even with simple check - opening private browser window, that way resetting the session, and calling the API over and over again - the results are inconsistent and TLS handshake times are long every time (about 2sec). Also, I've noticed that "Blocking" takes 2 additional seconds. – Jonas Petraška Feb 07 '19 at 22:59
  • @DourHighArch Where do set this ? – Jonas Petraška Feb 07 '19 at 22:59
  • 1
    Can this problem somehow be caused by the load balancer or network settings ? Would there be a benefit from switching kestrel for HTTP.sys ? – Jonas Petraška Feb 07 '19 at 23:25
  • Anecdotal: I've seen a SQL Server CLR that was calling out to an HTTPS resource (don't ask!) intermittently take 30+ seconds when the usual response time was ~500ms; this appeared to be due to CRL checking taking place, based on a wireshark trace that was taken, in an environment where CRLs couldn't be accessed. It could be something *like* this... – Rob Feb 08 '19 at 07:20
  • I mention the anecdote as this only occurred inside the SQL Server hosted CLR (at the frequency that we saw it), so was very much a CLR hosting environment specific issue – Rob Feb 08 '19 at 07:36
  • Sorry for not replying this long, haven't looked into this problem for a while. However, currently this problem has become a must to solve. I've tried to take the container and run it separately inside of Azure container instance, the results are the same. This got me thinking, since load balancer and service cluster is not the cause, can the kestrel itself or ssl certificate be the cause of this ? Maybe free Let's encrypt certificate causes this. – Jonas Petraška Mar 09 '19 at 21:22

0 Answers0