An Introduction to HTTP/2
HTTP/2 is a major revision of the traditional HTTP/1.1 web data-transmission framework, which has faithfully served the World Wide Web for fifteen years as the primary method of loading web assets through TCP connections. Rather than a ground-up rewrite of the protocol HTTP/2 is instead a re-expression of HTTP code, and utilises the same methods, status codes, and language semantics to tackle the challenges faced by the legacy HTTP framework today. Primarily, HTTP/2 looks to reduce load latency in web pages by increasing number of outstanding requests that a page can make without resorting to ‘hacks’ like domain sharding, concatenation, and spriting.
What is HTTP/2 used for/Why use it?
Developed by the Internet Engineering Task Force’s HTTP Working Group, HTTP/2 is based on an earlier SPDY protocol developed by Google and used to solve escalating costing problems within their network centre data usage and is composed of two specifications: namely Hypertext Transfer Protocol v.2 and the HPACK Header Compression format. Header compression in particular severely reduces the number of round-trips needed to load data fully; this is particularly useful for mobile clients, wherein typically you’ll see a round-trip latency of a few hundred milliseconds. The SPDY/2 framework was selected as the basis for the new system, and since the implementation of HTTP/2 Google has gone through with plans to remove SPDY support in favour of the new and improved protocols. Ultimately, improving your hosting performance.
How it Works
HTTP/2 uses binary protocols as opposed to the textual ones of the HTTP/1.x frameworks, as these protocols are more compact and easier to parse ‘on the wire’. On the older designs, there were four ways for a page to parse a line message; in the new framework, this has been reduced to just a single call. As well as this, the inclusion of full multiplex support means that the head-of-line blocking issues of legacy protocols have been eliminated, allowing for more than one request and response message to be ‘in flight’ over a single TCP connection at any one time. This is important as HTTP/2 still only allows for one TCP connection, due in part to the fact that most modern web pages use multiple sources. Having multiple connections from various points of origin increases the network resource usage of the browser beyond what is reasonable, so HTTP/2 instead uses server pushing and header compression to maximise data transfer and efficiency.
Non-browser applications, even more, packet-efficient ones such as VoIP, should also be able to utilise HTTP/2.x connections provided they’re already using HTTP. Despite this, HTTP/2 has so far been optimised primarily for browser usage, as this constitutes the core usage of the framework.
Online Security with HTTP/2
So far the HTTP Working Group have not required the use of encryption methods such as Transport Layer Security (TLS); despite this, they have defined a TLS profile including a cipher suite blacklist, and no browsers currently support HTTP/2 in an unencrypted state. Browsers which currently support HTTP/2 protocols include Microsoft Edge, Safari, Firefox, and Chrome.
Implementing the New Protocols
For the most part, HTTP/2 can be implemented without prior HTTP/1.x support. If you don’t implement the HTTP 1.1 Application-layer Protocol Negotiation (ALPN) identifiers, then TLS encryption support is also possible. For HTTP/2 over TCP however, you’ll need to process an upgrade from HTTP/1.1.
Alongside the absence of an encryption requirement, HTTP/2 has a couple of weak points. Cookies have not been improved much over HTTP/1, and despite their relatively innocuous nature cookies can still technically be used by hackers to gain access to your private systems.
How and When to Switch
Getting started with HTTP/2 isn’t too difficult from the client-side, all you’ll have to do is make sure your browser is up to date, as most major clients support the new protocols. Server-side, however, there’s a little more running around. You’ll have to ready yourself to move away from image-sprites, reduce the amount of CSS and Java concatenation on your pages, and ready your domain shards for coalescence by HTTP/2. To do the latter, you’ll have to make sure both shared URLs have the required TLS certificates. If you’ve not got direct control over which servers their pages are deployed to, it’s probably best to wait until you know your servers are updated.
Check With Your Host
Finally, speak to your WordPress hosting provider or server administrator in order to ascertain whether you’re HTTP/2-ready and once you’ve confirmed the infrastructure is there, roll out the new protocols as and when your visitors will statistically benefit from it the most. If you can’t contact your server host, there are open-source tools available online which you can use to test your server’s status.
