Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Why is it that Secured HTTP Connection (https) is Slower then than typical HTTP (http)?

Just interested in knowing only.

Thanks.

share|improve this question
    
Steve Gibson does an "TLS/SSL for Dummies" episode in his Security Now podcast .. read the transcript of listen to the audio .. grc.com/sn/sn-195.htm –  tomjedrz Jun 12 '09 at 16:38
    
See also the discussion here –  bobobobo Apr 19 '13 at 17:20

7 Answers 7

up vote 18 down vote accepted

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.

More information about TCP/IP connection establishment

More information about SSL/TLS handshaking

share|improve this answer
1  
+1 for mentioning the SSL handshake –  squillman Jun 12 '09 at 15:03
1  
+1 for providing the more detailed answer –  pauska Jun 12 '09 at 15:08
    
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

In simple words: Because it encrypts and decrypts the traffic, this requires processing on both sides (the server and the client).

share|improve this answer
    
This is incorrect, processing for the symmetric key communication takes less than 1% of CPU time. The overhead is from the handshake step, great diagram here. 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

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.
share|improve this answer
    
Good point about caching on the client side, which affects the perceived responsiveness of the page –  Dave Cheney Jun 12 '09 at 15:07
    
+1 for mentioning caching –  pauska Jun 12 '09 at 15:12

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

share|improve this answer

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.

share|improve this answer

Because it takes a little bit of time to encrypt the content, and the encryption generally increases the size of the content.

share|improve this answer

Like a number of people have mentioned Crypto is hard and the server needs to take the time to do it. Plus your browser and the proxys between you and the server can't/won't cache anything so you have to re-request all pages components on each new page.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.