Enabling SSL session for Jetty to speed up HTTPS r

2019-03-05 05:46发布

问题:

This is a follow up of my question here, where I found a big query time differences with HTTPS vs. HTTP requests: the larger the distance to the server was the bigger was this difference.

I found a nice explanation of this handshake overhead. And one cannot really solve that, but for further requests it is important to use a SSL session in combination with keep-alive. Keep-alive is turned on. But the SSL ID is different for every request (I'm using jetty and reading the ssl_session_id property).

It turns out that I need to change the client as well as the server according to this question, but I'm still confused and unsure (the answer for this question does not seem to sound solid):

For the browser: do I need to enable that somehow if I make javascript queries to my API?

For Jetty: Do I also need to turn off the allowRenegotiate setting for jetty as explained here? But it looks like this would have several security implications, where I do not fully if now allowing is safe or not (taken from the docs):

Set if SSL re-negotiation is allowed. CVE-2009-3555 discovered a vulnerability in SSL/TLS with re-negotiation. If your JVM does not have CVE-2009-3555 fixed, then re-negotiation should not be allowed. CVE-2009-3555 was fixed in Sun java 1.6 with a ban of renegotiates in u19 and with RFC5746 in u22.

回答1:

I'm not quite sure what you're actually asking for. Well HTTPS will always be slower than HTTP as it has more overhead.

However there's things you can probably do to reduce the response times. For example most Operating Systems are using a too small tcp initial congestion size. This leads to an additional roundtrip just for the TCP handshake. As the roundtriptime is usually somewhere between 20ms and up to several seconds (slow network to a server overseas) this can severly improve the time taken to establish a ssl connection.

Have a look at https://lwn.net/Articles/427104/ for linux systems. Kernels >2.6.39 or >3.x should do.