Why ever use relative protocols if I can use https?

Question

Living in Syria, I feel really unhappy when a (Facebook, G+, Twitter... etc) plugin doesn't work on 90% of the web.

The problem is that these (social) websites are not welcome in Syria (gov decisions), but still work perfectly using https. However, because their plugins use relative protocols, and most websites use http, then these plugins will eventually try (and fail) to load using http.

The question is: Why ever use relative protocols if you can use https?, isn't it always better to use https and have your users' data transferred securely?

I don't think giant websites care about https overhead, so what am I missing about the whole thing?

Answer 1

when we look at the https squence diagram http://blog.expressionsoftware.com/2011/02/https-sequence-diagram.html

we see that only the client's first requests (the handshaking step) is the overhead.

so I agree with you it is always better to use https...

maybe the missing thing is you still don't want to believe that people are lazy and don't care about the quality :)

this can be read too... http://www.codinghorror.com/blog/2012/02/should-all-web-traffic-be-encrypted.html

Answer 2

The only reason I find for not using SSL (HTTPS) is performance if you want to have responses within say 300ms.

The SSL hanshake could take a few rount-trip-time's that could add from very few ms in the same region (say client and server both in US East) up to 600 ms or more sometimes. I'm in South America so it could take more sometimes with servers in US.

Even when the sequence diagram looks simple, TCP has an initial congestion window that makes the protocol require at least one more RTT (round trip time) for the server to send the complete certificate to the client. Except for servers that change this initial congestion window (cwnd).

Additionally, the SSL protocol is more complex and there could be a "Change Cipher Spec message" that requires an additional RTT.

After SSL handshake, the extra work happens in the server and client encrypting and decrypting with a symmetric key. But it's not critical in my experience (maybe 5% of total CPU utilization).

My comment is useful for web services. Now, if we talk about web sites, I'd do everything with HTTPS.