Why is it that Secured HTTP Connection (https) is Slower then than typical HTTP (http)?
Just interested in knowing only.
Thanks.
Asked
Active
Viewed 3,185 times
3
-
Steve Gibson does an "TLS/SSL for Dummies" episode in his Security Now podcast .. read the transcript of listen to the audio .. http://www.grc.com/sn/sn-195.htm – tomjedrz Jun 12 '09 at 16:38
-
See also the discussion [here](http://stackoverflow.com/questions/149274/http-vs-https-performance/153448) – bobobobo Apr 19 '13 at 17:20
7 Answers
20
To open a TCP/IP connection requires 3 packets to be exchanged between the client and the server. The connection is then considered established, and the client can submit its request.
When SSL is added on top of the TCP/IP connection there are several additional interactions that have to happen before the connection is considered established.
Unless the latency is negligible between the client and the server (read, the same network), then it is likely that this additional latency, due to the additional round trips to exchange SSL handshaking data, not the CPU overhead of calculating the key material, is the major factor in the delay in establishing an SSL connection.
Dave Cheney
- 18,567
- 8
- 49
- 56
-
1
-
1
-
I am wondering how much time _CA certificate verification_ takes from SSL handshake total time (50-500 ms..?) – bobobobo Apr 19 '13 at 17:09
8
In simple words: Because it encrypts and decrypts the traffic, this requires processing on both sides (the server and the client).
pauska
- 19,620
- 5
- 57
- 75
-
This is incorrect, processing for the symmetric key communication [takes less than 1% of CPU time](http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html). The overhead is from the [__handshake step__](http://stackoverflow.com/a/153448/111307), [great diagram here](http://pic.dhe.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.itame2.doc_5.1/ss7aumst18.htm). It isn't from cipher computations either. It's from network transport time: Regular HTTP: __1) =>REQ 2) <=data__ HTTPS: __1) =>REQ 2) <=x509 CERT 3) =>CA Verify 4) =>Send symmetric key 5) <=NOW server can send data__. – bobobobo Apr 19 '13 at 17:18
7
As mentioned by other people there is the encryption and decryption steps for all transfers. There are two other issues though:
- The negotiation phase when you first talk to the server, in which the server and browser negotiate a key for the encryption process and your browser performs some checks on the servers certificate (it it checks yours if you are using client certs).
- The fact that no content (including the main page source, scripts, images and stylesheets) carried on a HTTPS connection should be cached by your browser, so it has to re-request objects it would otherwise get from cache every time it needs them.
David Spillett
- 22,754
- 45
- 67
-
Good point about caching on the client side, which affects the perceived responsiveness of the page – Dave Cheney Jun 12 '09 at 15:07
3
Jeff Moser just posted a good article on this explaining the ins and outs, handshaking etc.
http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html
Rob Bell
- 183
- 1
- 3
- 11
1
To add to pauska's answer:
Most web server platforms can add hardware/software to improve the performance of SSL on the server. This product does this.
Jim Blizard
- 605
- 1
- 5
- 12
0
Because it takes a little bit of time to encrypt the content, and the encryption generally increases the size of the content.
Jack B Nimble
- 1,505
- 1
- 10
- 13
-2
i have that establish secure connetion lag too... i look in chrome advanced parameter. scroll down to https/ssl and deleted all certificate relative to comodo (found them in the second or third tab, din't remember), never got that establish secure connection lag again hope that help
phil
- 1
-
That solution sounds very unlikely to work, and because of that you need to include some really strong evidence for it. Without evidence to back it up the only conclusion we can draw is that you did not perform your observations properly. – kasperd Apr 23 '15 at 19:47