TL;DR: Yes, but...
Background
HTTP has been the protocol the web has been built on since 1991 when version 0.9 was released. It has been the back bone technology nearly every network communicating device relies on. And for 24 years HTTP remained largely unchanged. But as all things time marches forward and so does technology. In 2015 HTTP2 was released to the world. With encrypting as a mandatory part of the technology it bring security; with multiplexing it brings increased response rate to resource requests, and with a push ability the server can respond with resources before the client even requests them. All this and more combine to make a very impressive iteration of the protocol.
Configuration
Using a very basic LEMP stack I setup a basic web server, then abused it with 10 requests per second over 5 minutes. This provides a baseline of the performance to expect from a specific set of hardware. Then I configured a SSL certification (as required for HTTP/2). Followed by a minor edit of the Nginx configuration blasted the same server with the same load. The result was a 1 for 1 comparison between HTTP 1.1 and version 2. The repo can be reviews over on GitHub.
The Good, The Bad, The Ugly
The Good
Performance was measurably increased. With multiplexing the many images where responded to in parallel instead of serial responses. Additionally the average response rate looks to have decreased by about 10%
The Bad
This is not really a bad thing, but HTTP/2 requires SSL and the associated configuration. Year ago an SSL certification use to be expensive. This is not so much an issue any longer thanks to Lets Encrypt. I am not sure I would use Lets Encrypt in a large scale production environment but it gets the job done. Configuration take understand Linux operation and Nginx configuration.
The Ugly
The performance gain was not as much as I had hoped. The main reason for this is the handling of the SSL. It does require CPU overhead to validate and process the traffic encryption. If you want to get fancy it is possible to off-load the SSL handling to a load balancer, thus leading the server to only process the request.
Additional Resources
- Google Web Fundamentals Introduction to HTTP/2
- https://en.wikipedia.org/wiki/HTTP/2
- https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-with-http-2-support-on-ubuntu-18-04
- https://http2.akamai.com/
Conclusion
All in all HTTP/2 provides a decrease in response time, enforces encryption and is not terrible difficult to enable. Using the more advanced features (suc as push) and a caching system HTTP/2 is an amazing improvement to a corner stop internet technology.
Extra images sourced from https://chadhagen.com/ . Go help them out, Chad's work is amazing.)
Top comments (21)
A drawback of HTTP/2 is also that it elevates HTTP from a text line readable stream to a binary one. Which means that you need a specific tool to work on it.
Not that big of a deal but HTTP/1.1 is an easy line protocol.
Very good point @rhymes . Though I imagine nearly any modern tool that supports HTTP would also have updated to support HTTP/2; else fall into the bin of irrelevancy.
Not really, being incompatible means a lot of stuff needs to be taken into account.
Rails doesn't really support http/2 for example, unless you put assets on http/2 enabled CDN and proxy the server. Heroku, server destination for many devs, doesn't support http/2
The issue is that by using just the CDN you need to change your pipeline because deploying a single merged JS file as most HTTP/1.1 apps do is not an advantage with HTTP. Also you don't get server pushes and other features.
The situation isn't that great in Python's land either.
Go's webserver enables HTTP/2 by default
Ah, so it is the web server (Puma) not the framework (Rails) that does not support HTTP/2. Bummer. Maybe use a Nginx proxy w/ HTTP/2 in front of a Passenger web server. Might do the trick.
Sounds like HTTP/2 in dev. is a no go for now in this situation. I would still push got HTTPS in dev. 'cause security.
Yes you can proxy with a HTTP/2 web server but you have to terminate the HTTP/2 connection at the proxy.
Rack (the underlying specification/interface) was designed for HTTP/1.1.
The good news is that they recently implemented early hints in Rails 5.2 and Puma
Python has a similar problem with WSGI based web servers.
What do you mean?
Blurry eyed mornings :|.
Thank you for the info. about Rails. Something I was not aware of. Nice that the up coming 5.2/Puma release will address this short coming. I look forward to reading up on it.
Very nice and well documented test, but I am surprised to that you have not seen more improvements on the speed gains, speacially because I had another impression after I read the Troy Hunt and Scott Helme articles.
Now I am curious why the differences in the results and I need to take some time to go hover all this articles on HTTP2 and try to find what is different in the methodologies used.
One of the biggest reasons you will see not that much speed increase in my results is due to the target website not having a massive amount of images. One of the big speed increases comes from the multi-plexing ability of HTTP/2. The more images on a site, the more speed increase.
Troy mixes up the dependency. HTTP/2 requires HTTPS, not the other way around. You can easily run HTTPS over HTTP 1.1
I also did not enable compression. I wanted to test the protocols alone, not with additional enhancements. That is an article for a later time.
Thank you for the additional resource. More ammo for the 'secure everything AND go fast' cannon. :)
That's will the reason for the small difference ;)
Not sure if is really mixing that concept. He really knows about this stuff and he have a lot of courses around it in Pluralsight and a famous workshop, Hack yourself first, that he presents all over the world and also in Pluralsight.
Fair enough... Looking forward for the next article on it.
Is TLS Fast Yet it is one more excellent resource that goes in very detail about TLS. It contains links to a bunch of other good content.
I also have a repo with links and notes about everything I know regarding HTTPS. Feel free to take a look on it to see if you find any new resource that can be of use to you.
Any reasons for that?
(For brevity, Lets Encrypt === LE.)
While LE is currently the third largest Cert. Authority in the world my hesitation to use them in a large scale production environment boils down to one factor: reliability. Per LE's own data up time in 2017 was only 98%. For vast majority of apps / sites this is fine.
A second hesitation I have is more of a personal experience one. A service that costs 2.7Milion USD per year (year end 2016) and growing. Someone has to pay the bills. Free services tend to go one of two ways: heavy marketing (email spam) for the better service or begin pivoting from
freetofremium. This would for enterprise to put in additional effort to migrate Cert. Auths. Double effort = wasted budget / time.The last bit that holds me back from recommending LE for the enterprise is the 3 month limit before renewal. Larger organization are not necessarily fast moving orgs. If automation / cron is not configured it could be weeks before someone is tasked to correct the issue. With year certifications the expiration is far enough away maintenance time can be scheduled and effort allocated. The return on investment is a bit better. Again, in cases wherein automation is not used.
Again, my recommendation only covers large scale, enterprise, critical systems. If you app/site/game/blog is getting less than millions of requests per minute Lets Encrypt is a great option. Infact, I use it...98% of the time :).
LetsEncrypt is connected to the legally nonprofit Linux Foundation. They're about as likely to switch to ads as Wikipedia is.
I was not aware of this, very good news indeed! Thank you for the info Michael.
I redact my concern over funding of Lets Encrypt and replace is with positive support.
QUIC is totally worth it :P
QUIC is going to be named HTTP/3 by the Internet Engineering Task Force (IETF).
Interesting in this article is that:
HTTP/3 spec looks impresses. Forgoing TCP for UDP is an interesting change of process.
I wonder when an official release will become available; following that when the major web servers will support it.
I know :D dev.to/inductor/what-the-flip-are-...
Must say that those images intrigued me more than http2 😄Thanks for linking source!
Everyone seems to love the meaningless infographics by Chad Hagen. They are indeed intriguing.
Totally unrelated, but what distro, wm & theme is that?
Ubuntu 18.08 using Gnome, Paper theme. Screen captures are dropped into screely.com for presentation framing.