0

There are many great articles explaining how SSL/TLS works on this site, but I would like to bring in the performance issue. The thing is that I am serving my web content over HTTPS and the SSL handshake takes a lot of time.

As much I understand at the moment the connection thru HTTPS is created as follows:

  • TCP handshake
  • SSL handshake
  • HTTP data

Now, considering that I am not allowed to use the keep-alive header in HTTP, does that mean that with every request all those 3 points are triggered? My empiric tests show, that the SSL handshake part that is extra from plain HTTP takes around 200-300ms. For loading the main page the app is making 10+ requests, so that would mean 200*10 = 2 seconds, right? That is too much.

So the question is: How can I optimize those routines? And also, how is the performance distributed between server and client during SSL handshake? Seems like the server has to do a lot more computation, is that correct?

Erki M.
  • 101
  • 3
  • Correct server configuration will reduce overheads but at some point you will hit a computational bottleneck. Major organisation often distribute the load across multiple servers. But if you have physical control over your web server, you could install a hardware accelerator. – LateralFractal Mar 09 '14 at 01:28
  • You may find this link helpful: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html Why can't you use keep-alive? That's probably the best trick to improve performance – paj28 Mar 09 '14 at 11:19
  • the question is a little bit misleading, it's not that I am not allowed to use keep-alive, it just added this to get an answer how big companies, that don't use keep-alive (to have maximum availability) get over this problem. Is it hardcore hardware? Secondly I am thinking how to be safe from keep-alive based DoS like this, that I have successfully executed against my webserver. – Erki M. Mar 11 '14 at 18:19
  • also, if I am correct on the statement that SSL negotiation is a lot resource-heavier on server side, isn't it possible to make the server crash by sending it a lot of SSL negotiation requests, similar to SYN-flood? Sorry for any n00b stuff, I am just starting to learn this area. – Erki M. Mar 11 '14 at 18:23
  • Late but: spuriously doing (nonabbreviated) SSL/TLS handshakes is indeed fairly costly and can be a DoS attack but not usually a crash, although if from the same or otherwise known-bad IP(s) a server can reject them cheaply. Classic only-RSA keyexchange requires more work on server than client; the PFS keyexchanges (DHE and ECDHE) which are now often preferred and in some cases required are more evenly divided, almost exactly so with DSA or ECDSA (respectively) authentication. – dave_thompson_085 Jan 18 '17 at 17:15

2 Answers2

2

When your website references 10 external files, these will not be loaded one after another. The users web browser will request them all at the same time and load them in parallel. That means the total time is 200ms for loading the HTML file and another 200ms for loading all the images, scripts, stylesheets etc. which are mentioned in it.

The RFC 2616 states that web browsers are only allowed to open two connections to each server at the same time, but nowadays all major browsers ignore this and allow a lot more parallel connections (how many varies from browser to browser and is often configurable by the user).

Philipp
  • 49,384
  • 8
  • 129
  • 160
  • Sort of. Most web browsers have a limit on how many connections they'll make at once to a single web server (eg. Opera defaults to 16 connections per server). – Mark Mar 09 '14 at 03:50
  • @Mark Firefox allows 6 by default, but you can override it by changing the parameter network.http.max-persistent-connections-per-server in about:config. Answer edited to mention this. – Philipp Mar 09 '14 at 04:02
  • Many websites get around this by hosting content on multiple sub domains. I would be interested to know whether a 'server' is classified as a domain or IP address. – David Houde Mar 09 '14 at 05:21
1

So you are required to use SSL which adds noticeable overhead to connection setup, but you are not allowed to use persistent connection (e.g. keep-alive) which would make that overhead less relevant because you do multiple requests inside the same connection. This restriction sounds stupid to me.

You still have some options to speed things up:

  • SSL session reuse, which reduces the time or the SSL handshake on repeated connections to the same server.
  • Make less requests, e.g. merge multiple script or style includes into on file or serve them inline inside the HTML. Use data-URLs for small images etc.
  • Spread the load over parallel connections (see other responses for limits of this approach).
Steffen Ullrich
  • 201,479
  • 30
  • 402
  • 465