HTTP is the protocol on which the Web is built. It’s the way that browsers send requests to a server and get back content. CERN and Tim Berners-Lee created it in 1989, when the Internet carried pages that were very different from today’s Web. A page was basically text, perhaps with a few images. Connection speeds were usually measured in kilobits per second. Today’s Web pages are far more complex, with images, videos, scripts, and stylesheets, often from many different servers. Connections are vastly faster. What was good enough for the simple pages of the nineties is inefficient for today’s needs.
HTTP/2, the first update since the 20th century, became an IETF standard in 2015. It was an outgrowth of SPDY, a protocol which Google developed to improve HTTP performance. SPDY is now considered obsolete.
HTTP/2 changes the way requests travel so that loading a page requires fewer connections, more information can fit in fewer bytes, and more data can be sent in parallel. It improves communication without affecting the content of Web pages.
Major Web browsers and servers support it. The Apache, Nginx, and IIS servers all accept HTTP/2 connections. The latest versions of Chrome, Firefox, Opera, Internet Explorer (on Windows 10), and Edge can use it with a compatible server. For the most part, browsers and servers make it available only for secure (HTTPS) connections.
Compatibility
HTTP/2 changes only the way information is sent over the communication channel. Its request types, headers, and responses remain the same. Push requests are a new feature; a server can send data to the client without first getting a request.
Updating a site to HTTP/2 has no effect at all on the content of Web pages. No changes are required. Even error responses, such as “not found” and “server unavailable,” are exactly the same as before. Server push could be put to new uses, but currently it’s just being used to preload content that would be loaded anyway. Unless you’re a developer working on software that involves communication protocols, you don’t have to do anything to take advantage of it except update your software.
Efficiency
The HTTP protocol is based on “connections,” negotiated communication paths between a client and a server. HTTP/1 allows only one outstanding request per session. One request (e.g., for an image) has to finish before the connection can start another. A client can set up multiple connections in parallel, but having lots of connections is a burden on the server and can slow it down.
HTTP/2 allows multiple parallel requests on the same connection. They can finish in any order. This means less waiting for a request to complete. The client encodes request headers as compressed binary rather than text data, adding to the efficiency.
Security
As a practical matter, HTTP/2 requires TLS security (HTTPS connections). The specification doesn’t mandate it, but most browser and server implementations support HTTP/2 only over TLS.
A quick note on terminology: SSL and TLS are the same thing. TLS has been the official name for many years, but the older name has stuck. HTTP/2 specifies that if TLS is used, it has to be at least version 1.2. This eliminates a problem in older implementations, where a malicious server could force a browser back to an old version of SSL and take advantage of known bugs in it.
Web Application Firewalls (WAFs) need to be updated to support HTTP/2 to provide full protection.
Version 1 of HTTP won’t vanish for many years, since some servers are never updated. Servers that don’t support secure connections won’t be able to adopt HTTP/2. We can expect, though, that HTTP/2 will soon carry the majority of the traffic on the Internet.
