Post Here to Contact Site Administrators and Moderators

I have read on the Internet that SSL (HTTPS) sites are often faster than HTTP sites; but not sure if this is the reason it seems faster.

Is that partly because encryption includes compression? It wouldn't seem to be transferring enough data each time to make a noticeable difference though.

This is not the case. In fact, SSL works like this (short introduction to encryption theory):

First, we need to establish the difference between asymmetric and symmetric encryption methods.

In symmetric encryption a cipher is used to encrypt as well as decrypt the message. The cipher is shared between the sender and the receiver beforehand. Advantage: keys can be smaller (typically 128-bit or 256-bit) and it allows for two-way communication. Disadvantage: whoever knows the cipher can encode as well as decode it.

Asymmetric encryption works with two different ciphers: one (the "public" key) is used (only!) to encrypt the message. To decrypt it one needs the other "private" cipher. You can send around your public key without caring for who knows it, because only the encryption is possible. As long as you keep your private key to yourself you alone can decrypt anything encrypted with your public key. Advantage: you don't need to share the (private) key with anyone. Disadvantage: allows only a one-way communication and uses significantly larger keys (1024 or 2048 bit for RSA nowadays).

The most common asymmetric algorithms are RSA and elliptic curves (ECC). RSA is based on the fact that integer factorisation is difficult and expensive computation-wise. Basically you build the product of two very large prime numbers: the product is easy to calculate (and published) but without knowing the factors it is difficult to compute them (the private key) from the product. ECC computes the discrete logarithm of a random elliptic curve element. The elliptic curve is built over a Galois field (not the real numbers) and the discrete logarithm is computed in respect to a point at infinity.

As asymmetric encryption only works one-way, how is it used for information exchange, say, between a web server and the browser? The idea is to use a handshake-procedure to establish a session:

1) Server sends his public key to client.
2) Client creates a symmetric session key, encrypts it with the public key of the server and sends it back
3) Server decrypts the session key and
4) both client and server use this symmetric key for the duration of the session

All these algorithms do NOT compress anything at all. In fact they are neutral to the amount of data being transferred.

I hope this helps.

bakunin

Update: here is a document explaining why HTTPS is faster than HTTP.

It boils down to a Google-developed additional session layer (SPDY) from which only HTTPS profits. Basically it is not HTTPS vs. HTTP but multiplexed sessions over a single TCP connection versus unmultiplexed sessions. It would be possible to do HTTP over SPDY too (it is just not done). HTTP2 is basically SPDY standardised and further developed.

In principle HTTP is slightly faster than HTTPS: there are caching facilities so that not every retransmission has to be originated by the client. HTTPS lacks that because relaying stations cannot read what they transmit.

How SPDY speeds up things is especially via the session multiplexing. This gains lots of time because of the delayed TCP-ack, which takes 500ms.

bakunin

Site is a bit slower because I bumped up GoogleBot to index the site at "full pull" speed; and this is normally to high of a pull rate and will need to back it off soon.