So what is HTTP/2?
A little background
If you’re a web developer (or indeed any developer nowadays) then you really should know HTTP as this is the de facto protocol for client/server communication on the web. HTTP is in essence the TCP/IP protocol for the web using ports 80 and 442 by default (for non-secure and secure communication respectively).
HTTP dates back to the late 1980’s and early 1990’s so it’s a mature protocol which was designed long before the modern web app of today. Thus, many conceivable performance enhancements have been proposed over the years that saw things like headers (initially missing from the 0.9 HTTP specification), VERBS (HTTP initially consisted only of GET requests), content types and much more.
However, these enhancements were working within the constraints of the original HTTP specification and the HTTP/1.1 was pushed to the maximum. It greatly needed a reboot. And in 2015 HTTP/2.0 was born.
HTTP/2.0 is born
Through a partnership between Google (and its now deprecated SPDY protocol) and a number of other leading bodies, the HTTP/2.0 specification was drafted which focused on a number of major shortcomings in the HTTP/1.x specification. Primary targets for optimisation included:
- Prioritise binary content over text
- Header compression
- Inherrant security
- Server-side push
Whereas earlier versions of the protocol were purely text based, HTTP/2.0 is a binary protocol consisting of a HEADERS frame and a DATA frame (analogous but not the same as the headers and body in HTTP as you know it today). Frames are grouped into streams. Because of this, only a single TCP connection is required to transmit multiple resources, as various streams can be sent to the client and easily reconstructed using the stream id to decompose frames accurately.
With the multiplexing described above, clients can eagerly make several requests for resources knowing the server can send them on the same connection. However, servers utilising a HTTP/2.0 connection can be a little more pro-active and actually push content to the client knowing it will be needed. The server will notify the client that it is performing a server push using a special frame called a PUSH-PROMISE which informs the client that it is sending data that it hasn’t asked for, but thinks it will need. Therefore when the client later realises it needs this resource, it already has it and knows where to get it without contacting the server.
With all this lovely asynchronous goodness and pro-activeness on a single stream, it is conceivable that the client could be waiting longer for a resource on a TCP connection as its being intermixed with other content. This has been though of though and clients can tag a request with a priority so that it can later send the server a PRIORTY request frame and switch priority levels of resources being returned, thus allowing it to get the most important content first. Without this the server just processes resources without any priority which could in fact slow down the delivery of key resurces.
The most hotly debated part of the HTTP/2.0 specification was the debate on whether all communication through HTTP/2.0 should be secure (using TLS). While the final decision was that this was not mandatory, browser vendors disagreed and all major browsers at the time of writing will only communicate over HTTP/2.0 when TLS security is in place. Thus, all HTTP/2.0 communication today in web browsers are via HTTPS which is a good thing for security and privacy.