

HTTP vs. HTTPS - mef
https://www.httpvshttps.com/

======
Someone1234
According to Chrome the difference is "waiting" for the server response (47 ms
Vs. 473 ms). You can tell that nginx is configured very differently between
the two response types just by looking at the response headers.

I suspect the author set out to prove this and then made the environment fit
their agenda. Nothing to see here. I'm sure Spdy is faster than HTTP/1.1 but
nowhere near what this site claims.

~~~
billyhoffman
The "Waiting" time listed in the Network panel of Chrome is actually the TTFB
for each HTTP request/response. It is the latency from browser to server,
server processing, and latency coming back. And because of the difference
between latency and our huge bandwidth connections, your browser spends most
of its HTTP networking time waiting.

This is exactly where the "SPDY vs HTTP" factor comes in. With HTTP, you
request each item, and wait for a response. This can only be done one item at
a time[1] per HTTP/TCP connection, with a limit of 2-6 (depending on the
browser) HTTP/TCP connections per unique hostname. As I mentioned in a comment
below, this benchmark is using a single hostname, which is the worse possible
situation for HTTP.

SPDY, or HTTP/2, instead using a single TCP connection, and multiplexes all
the requests over it. In other words it can be downloading pieces of many
other responses, all while waiting on other requests.

[1] - Yes, I am ignoring HTTP pipelining, because every other person who
implemented a piece of HTTP software did as well. And no, neither I nor anyone
else cares about older Opera supporting it :-)

~~~
Someone1234
But I am seeing the initial page response take longer on HTTP than HTTPS, not
even just the subsequent images...

Everything on the HTTP channel is slower, even stuff that shouldn't be.

------
mtmail
Doesn't this say more about Spdy than https?

~~~
billyhoffman
Its not even HTTP vs SPDY. Its HTTP vs SPDY, when all content is coming from
the same hostname. This is the best possible environment for SPDY, and the
worse possible environment for HTTP.

You are looking at one TCP connection for SPDY, with everything multiplexed.
With HTTP, you are looking at, best case, 4 TCP connections to the server,
that all start cold, doing 350+ requests in parallel. That's not even
considering the potential for the server push feature with SPDY.

I love SPDY and all, but this is not even close to a real world scenario.

~~~
kuschku
I don’t know what multiple XORs have to do with SPDY, but yeah, they should
have done it with one site, a CDN for images, some javascript loaded from
weird other CDNs, etc.

—— [1] Multiple XOR –> Multiplexor –> Multiplexer, an electronical circuit
that hakes multiple bundles of lines and returns the values of the bundle
which has been selected via the control input.

~~~
acdha
Multiplexing matters if you make 300 requests: with HTTP 1, you have to submit
a request and wait for each response to transfer completely before making the
next one (HTTP pipelining was supposed to solve this but has never been
enabled by default because compatibility problems).

With SPDY, you can request all 300 requests up front and receive replies out
of order so the server can send each chunk of data as it's ready.

------
underyx
>For best results, disable plug-ins

Why? It's perfectly reasonable to be more concerned with real life behaviour
than with benchmarks under optimal conditions.

~~~
Benferhat
Each plugin is a potential confounder.

------
zwetan
I don't want to be a killjoy but here I got HTTP faster than HTTPS

3 tests

    
    
      63%
      59%
      60%
    
     Mac OS X 10.9.5
     Google Chrome 39.0.2171.71 (64-bit)
     Google Chrome Helper disabled

~~~
stffndtz
Off-topic but how do you disable Google Chrome Helper?

------
rooted
Why do the images load in a different order between https and http? Https
seems to load them in order and http seems to randomly fill them in.

------
ikeboy
In a regular browser chrome with all my extensions, https is faster by a
factor of 2-3, but in incognito mode, they're about the same.

------
anthumchris
Sorry, everyone. I'm the site's author, and I increased the ulimit and
worker_connections to 4096, so you should see better perfomance and no more
errors now. My apologies...I'm a web guy, not a networking guy. Rookie
mistake.

And yes, you did break it :/

------
shmerl
Well it doesn't look like a fair comparison, it uses SPDY for HTTPS.

------
mittsh
Of course SPDY keeps the same TCP connections alive, the encryption and even
TLS handshake time is insignificant compared to the latency in creating a new
connection for each HTTP request.

------
ommunist
Looks pointless to me. Because choosing between turning your resource to user
with http or https is not about speed. There are other considerations on the
first place.

~~~
abraham
It's not pointless because many sites don't care about privacy/security so
speed is more likely to sell them on TLS/SPDY.

~~~
ommunist
Thank you, you are right from the marketing point of view.

------
coherentpony
Faster for the client or for the server?

~~~
anthumchris
for the client

------
magicseth
Try it a second time, it gets faster.

~~~
billyhoffman
It does. That is because, if you look at TLS handshake, they are using session
resumption to avoid 1 RTT and the need to renegotiate ciphers and session
keys.

[http://moz.com/blog/enabling-https-without-sacrificing-
web-p...](http://moz.com/blog/enabling-https-without-sacrificing-web-
performance)

------
aosmith
Can we disable SPDY? That's like comparing FTP and sockets...

------
dangayle
And we broke it.

~~~
anthumchris
Ha. My apologies, wasn't expecting so much traffic. Fixed now.

