
HTTPS' massive speed advantage - nouney
https://www.troyhunt.com/i-wanna-go-fast-https-massive-speed-advantage/
======
jimktrains2
> Well, almost, let's address the "It's not fair" whingers. The HTTPS test is
> faster because it uses HTTP/2 whist the HTTP test only uses HTTP/1.1. The
> naysayers are upset because they think the test should be comparing both the
> secure and insecure scheme across the same version of the protocol. Now we
> could do that with the old protocol, but here's the problem with doing it
> across the newer protocol [is that HTTP/2 over TLS]

This doesn't invalidate the argument that you're comparing two things and
claiming you're comparing two other things prima facia. For this use-case
HTTP/2 will be faster, with or without TLS (if it could be tested). Claiming
that it's the TLS that's speeding up the connection, which is what you mean
when you say http vs https) is just plain wrong.

~~~
richardwhiuk
But the other point is that https now means HTTP/2 or HTTP/1.1, where as http
always mean HTTP/1.1 - so I'm not sure that's true.

~~~
tedunangst
If https can mean one of two things, but http2 clearly means only one thing,
why would anybody choose to use the term https unless they are trying to be
deceptive?

~~~
c22
Or of they're trying to refer to the thing that http2 is not?

------
shawkinaw
It's not about fairness, it's about accuracy. You can't accurately say this is
just comparing HTTP and HTTPS; it's comparing HTTP/1.1 and HTTPS/2, why can't
you just say that?

It's especially irksome that "httpvshttps.com" complains when your browser
doesn't support HTTP/2, saying the results will be inaccurate. If the site
were called "http1vshttps2.com" I would agree, but it's not.

~~~
danudey
Looked at another way, it's comparing the latest HTTPS (2) with the latest
HTTP (1.1).

Looked at another other way, there are huge speed advantages that you can only
get if you go with HTTPS.

You aren't guaranteed those advantages if you end up stuck with HTTPS/1.1, but
that just means you're using an old stack which you should (and can) upgrade
(unless you're using IIS).

~~~
josteink
This speed advantage could have been present for plain HTTP as well, if not
someone with an agenda had declined to make plain HTTP supported in HTTP/2.

Actually the whole HTTP/2 name is massive misnomer (since it doesn't actually
support HTTP) and is the closest thing I can think of as technical newspeak as
far as internet protocols are concerned.

Marketing this as a new HTTP protocol version when it clearly wasn't was just
shady tactics and bad propaganda. The whole thing stinks.

~~~
WorldMaker
« if not someone with an agenda had declined »

Because privacy and security by default are a bad agenda to agree to?

« the whole HTTP/2 name is massive misnomer (since it doesn't actually support
HTTP) »

HTTP/2 is backwards compatible. It may not be your idea of the right direction
for HTTP/1.x, but that doesn't make it a misnomer. To be honest, the only
people that can decide if it was the right name for it are the IETF and they
already made that decision. There's a reason that the name SPDY looked nothing
like HTTP, because Google left that decision to the IETF as the standards body
controlling the fate of the HTTP protocol.

~~~
josteink
> Because privacy and security by default are a bad agenda to agree to?

Taking away people's ability to host servers and services for themselves
without having to register with a DNS provider and a CA are two major privacy
violations, and a roadblock to easy application deployment of applications on
your own LAN.

So yes, it's a bad agenda. Because it's not "by default". It's the only
choice. You can't choose not to incriminate yourself and your identity to a
centralised internet registry if want to host a service now.

You may not realise it, but once again you as a representative of the http/2
crowd is using wildly misleading language.

------
Ono-Sendai
Pretty stupid article, -1 flamebait.

One thing I have always wondered about these waterfall comparisons is why http
1.1. is slower. Since http 1.1 has keepalive, a browser should be able to send
multiple requests upfront to the server, and the server can then stream them
back. The lower limit on transfer time should therefore depend only on
bandwidth.

~~~
JonathonW
The big thing that HTTP/2 brings as far as pipelining is concerned is that
requests and responses can be multiplexed over the same connection to avoid
the head-of-line blocking problem with HTTP/1.1. HTTP/1.1 requires pipelined
responses to be sent strictly in the order they're requested; HTTP/2 can send
responses in any order or even multiplexed/interleaved (hence the network
activity graph from the OP).

Also, most browsers don't enable HTTP pipelining by default-- they'll reuse a
connection if possible, but won't make multiple requests at once for
compatibility reasons. Chrome even supported it for a while, but had to remove
it because it didn't work (bugs in Chrome, bugs in servers, and the head-of-
line blocking problem made it not worth keeping) [1].

[1] [https://www.chromium.org/developers/design-
documents/network...](https://www.chromium.org/developers/design-
documents/network-stack/http-pipelining)

~~~
bsdetector
Head of line blocking is mostly a theoretical concern not a practical one.
Since browsers use 6+ connections at once, a large slow request will only hold
up a few resources and usually doesn't affect the page load speed by much. In
fact, as shown recently interleaving can actually slow down the page
rendering. Then there's the priority system, an inversion of which caused
Google Maps to load far more slowly over HTTP/2\. The main problem solved by
interleaving responses is when there are 6 slow resources that tie up all the
connections causing deadlock, which is because of browsers capping the number
of connections.

Google spread a lot of FUD in their push to get SPDY standardized. For
instance they _never_ compared to pipelining, which is relevant because
Microsoft found that with pipelining HTTP was essentially just as fast.
Google's mobile test where they claimed ~40% speedup used 1 SPDY TCP
connection for the entire simulated test run of many sites vs new connections
per site for HTTP -- a simple mistake? Maybe, but they didn't take any steps
to correct it once they were made aware of it.

------
JoelBennett
Despite the calls of "it's not fair!", I can see what he is getting at. From
the end-user perspective, it doesn't matter what the underlying technology is:
if it provides a faster (and more secure) experience, it's a win.

If there was some huge drawback to using HTTP/2, I can see why people might
cry foul, but whether they like it or not, HTTP/2 is coming, so we might as
well embrace it.

~~~
WorldMaker
Right, users see HTTP and HTTPS, they don't see /1.0 versus /1.1 versus /2.

(There's a good argument that users seeing HTTP versus HTTPS was a mistake,
too, versus just secure/unsecure markers in browsers. TLS shouldn't have
needed a new port number and URL prefix... but it is way too late to fix that
now.)

------
falcolas
IMHO, when AWS uses HTTP/2 and not HTTP/1.1 over TLS, then you can start
claiming that https === HTTP/2\. Until then, you've moved the goalposts well
beyond what most of your peers would consider to be reasonable.

As a side note - what is the standard regarding multiplexing for terminating
HTTP/2 proxies: i.e. how much multiplexing could make it across that boundary?
Or is that a bridge we haven't crossed yet?

------
walrus01
Fun history: does anyone remember 32-bit/33MHz bus PCI crypto accelerator
cards? I remember seeing them for sale around 2000/2001 with openbsd driver
support.

[https://www.google.com/search?num=100&ei=oSGRV9uAHM2OjwOPxZK...](https://www.google.com/search?num=100&ei=oSGRV9uAHM2OjwOPxZK4AQ&q=pci+crypto+accelerator+card&oq=pci+crypto+accelerator+card&gs_l=mobile-
gws-
serp.3...4023.6532.0.7152.12.12.0.0.0.0.221.1390.4j6j1.11.0....0...1c.1j4.64.mobile-
gws-serp..1.10.1166...35i39j0i22i30j33i21.cjLimKjUPlQ)

------
Grue3
Imagine how fast it would be if the browsers didn't artificially restrict
HTTP2 to HTTPS only. HTTP over HTTP/2 would be faster and easier on the CPU.

------
jonathanoliver
Is it just me or is his HTTPS website down?

~~~
thewavelength
Works for me.

------
bullen
This would be interesting if it compared the energy required in joules!

------
josteink
Trollpost. Flagged.

