Limited persistent connections.
Back in the days when HTTP 1.1 came out, the RFC 2616 specification said in section 8.1.4 entitled “Practical Considerations” that a user agent can only have two maximum connections to a domain at any point in your life.
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.
Over the years, browser developers gave the middle finger to this recommendation. Don’t believe me? Take a look at the current state of the browser connection limitation issue from Browserscope. You will see today’s modern browsers ignore the HTTP 1.1 recommendation completely:
|Browser||Connections Per Host||Maximum Connections|
So if you are using Internet Explorer 11 and are visiting a web page, you are breaking the HTTP 1.1 law. With IE 11, there can be up to 17 connections in total downloading data at the same time across multiple domains. But, you can only have up to 6 connections per domain.
Fully knowing the above, I’ve have always put my biggest resources on another domain to make the throughput and user experience better and faster. Back when I used to run a very popular website that had a lot of images on the page, I decided to get around this limitation and store them all in what I called a media repository.
The technique to this day is called Domain Sharding. With domain sharding, if you run a WordPress website and dedicate another domain to store your media files, you can get better throughput by having the browser download (in the case of Safari) 6 resources from your WordPress site, and another 6 resources from your image repository site for a total of 12 connections concurrently downloading in parallel. Ohhhh handcuff me!
This worked well if the IP address of the domain was already cached and known by the browser. If the browser didn’t know about the domain’s IP address, it would have to go out and do a DNS lookup which is really a painfully slow operation. So it wasn’t very good to load your web page up pointing at too many external domains. Doing so, you would be a candidate for the “Your Website Sucks Award” from Vincent Flanders because you slowed down the page load with stupid junk.
Knowing this, I tried to stay out of the spotlight and only used one domain to point at my hypermedia assets.
And along comes HTTP/2…
In May of 2015, the IETF released their stamp of approval for HTTP 2 in RFC 7540. Without getting into too much detail and specifics about the new protocol, you can read bore yourself to death here.
What becomes of this is that the technique of using domain sharding to improve page loads is no longer needed. No longer will one request be made per connection and multiple connections needed to run in parallel. Instead, the new protocol uses multiplexing, whereby only one connection is used for multiple requests and responses.
If you get the sense that multiplexing has to do with some bi-directional streaming and unique stream identifiers, that would be the right inclination. To run the new HTTP 2 protocol, you must have support between the browser and server.
HTTP/2 browser support
On the browser side, all modern browsers to date support HTTP/2. Some will only support it with a crytographic SSL-like Transport Layer Security (TLS) enabled. Others, over clear text. This is conforming to the HTTP/2 specification and of the negotiation between client and server.
To determine what browsers currently support HTTP/2, you can refer to the CanIUse.com website. Pay attention to the notes with each browser brand and version.
Desktop browser support
- Microsoft IE 11+ (HTTP2 with TLS via HTTPS only and Windows 10+)
- Microsoft Edge 13+ (HTTP2 with TLS via HTTPS only)
- Google Chrome 51+ (HTTP2 with TLS via HTTPS only and ALPN)
- Opera 38+ (HTTP2 with TLS via HTTPS only)
- Safari 9.1+ (HTTP2 with TLS via HTTPS only on OSX 10.11+)
- Firefox 45+ (HTTP2 with TLS via HTTPS only)
Mobile device browser support
- iOS Safari 9.2+ (HTTP2 with TLS via HTTPS only)
- Chrome for Android 50+ (HTTP2 with TLS via HTTPS only)
- Android Browser 50+ (HTTP2 with TLS via HTTPS only)
HTTP/2 server support
An up to date list of HTTP servers that support version 2 are available at Github. The top 4 HTTP web servers in the world with the most market share all support the protocol.
- Microsoft IIS 10+
- Apache 2.4.17+
- Nginx 1.9.5+
- Google GWS (not an available product, only used by Google)
How fast is HTTP/2 versus HTTP/1.1?
To get a sense of the difference between HTTP 1.1 and HTTP 2.0, watch this comparison demo over CloudFlare’s network. In my test case, there was a 100% improvement:
You can also run the Akamai HTTP/2 demo. In this demo, I got a consistent 240% improvement:
But Can I Use HTTP/2 Today?
On the browser end, yes as we’ve seen. Just go download the current version. But on the server end, it depends on your host. Most hosting companies do not use bleeding current edge and stay a few versions back. In my case, at A Small Orange, I can see I am running on Nginx:
HEAD http://www.kobashicomputing.com 200 OK Connection: close Date: Fri, 01 Jul 2016 07:39:46 GMT Server: nginx Vary: Accept-Encoding Content-Type: text/html; charset=UTF-8 Client-Date: Fri, 01 Jul 2016 07:39:46 GMT Client-Peer: 188.8.131.52:80 Client-Response-Num: 1 Link: <http://kobashicomputing.com/wp-json/>;; rel="https://api.w.org/" Ngpass_ngall: 1
nginx -v nginx version: nginx/1.9.4
Here I see that A Small Orange is running Nginx version 1.9.4. We saw above in server support that HTTP/2 wasn’t made available until version 1.9.5. So presently, my sites are not using HTTP/2.