HTTP/2

HTTP/2 (originally named HTTP/2.0) is a major revision of the HTTP network protocol used by the World Wide Web. It was derived from the earlier experimental SPDY protocol, originally developed by Google. HTTP/2 was developed by the Hypertext Transfer Protocol working group httpbis (where bis means “second”) of the IETF (Internet Engineering Task Force). HTTP/2 is the first new version of HTTP since HTTP 1.1, which was standardized in 1997. The Working Group presented HTTP/2 to IESG (Internet Engineering Steering Group) for consideration as a Proposed Standard in December 2014, and IESG approved it to publish as Proposed Standard on February 17, 2015. The HTTP/2 specification was published as RFC 7540 in May 2015.

The standardization effort was supported by Chrome, Opera, Firefox, Internet Explorer 11, Safari, Amazon Silk, and Edge browsers. Most major browsers added HTTP/2 support by the end of 2015.

According to W3Techs, as of November 2017, 20.5% of the top 10 million websites supported HTTP/2.

Advantages of HTTP/2 over HTTP/1 and others

Your browser will still send requests to a server and get responses with the assets needed for the web page to look as it should, but some nuances in between will change. HTTP/2 supports queries multiplexing, headers compression, server push, priority, binary encoding format and more intelligent packet streaming management. This results in reduced latency and accelerates content download on modern web pages.

1 ) Multiplexed Streams

Remember the congestions caused by many connections passing the resources such as text, fonts and pictures from the server to your browser? Multiplexing eliminates this problem by making those assets into smaller parts, passing them all via one connection, and then reassembling the resources after they’ve reached the final destination, the browser.

2) Header Compression

In HTTP/1, every request sent has a small piece of additional data attached — HTTP headers — that describe how a browser or a server behaves. On average, browsers are able to make about six connections at once, but given that the number of connections needed to load a typical web page can be up around 100, this leaves a lot of data to be retrieved, which takes time and bandwidth.
When an HTTP/2 connection is established, all the headers are packed into one compressed block to be sent as a unity. It gets across faster, and when the transmission is finished, the header block is decoded.

3) Server Push

Server push represents a more efficient way to deliver assets to a browser. In an HTTP/1 environment, the HTML page is sent to the browser, the browser has to parse it and decide what assets it might need, then request those assets from the server.

HTTP/2 is more proactive in this regard, sending assets that the browser is likely to need without it having to ask. These assets go to the browser’s cache, and are available immediately if and when they’re needed, which is a plus for performance.

4) Prioritization

In HTTP/2 it’s possible to prioritize the requests, so a request can be received from the other if it’s high prioritized. This normally useful in a web page that contains a large number of resources such as JavaScript or CSS files.

5) Binary Encoding

The textual format has some extra overhead and needs to be refined, while the binary one does not need any parsing. It’s also a lot more compact. Additional work of a server means additional time to wait for the web page to be loaded. That is why the binary format, with its being easier to process, is a justified enhancement.

Binary Framing Layer

The “layer” refers to a design choice to introduce a new optimized encoding mechanism between the socket interface and the higher HTTP API exposed to our applications: the HTTP semantics, such as verbs, methods, and headers, are unaffected, but the way they are encoded while in transit is what’s different. Unlike the newline delimited plaintext HTTP/1.x protocol, all HTTP/2 communication is split into smaller messages and frames, each of which is encoded in binary format.

As a result, both client and server must use the new binary encoding mechanism to understand each other.

6) Intelligent Packet Streaming

With the new binary framing mechanism in place, HTTP/2 no longer needs multiple TCP connections to multiplex streams in parallel; each stream is split into many frames, which can be interleaved and prioritized. As a result, all HTTP/2 connections are persistent, and only one connection per origin is required, which offers numerous performance benefits.

Reduction of number of connections is a particularly important feature for improving performance of HTTPS deployments: this translates to fewer expensive TLS handshakes, better session reuse, and an overall reduction in required client and server resources.

Upgrading to HTTP/2

The switch to HTTP/2 cannot happen overnight: millions of servers must be updated to use the new binary framing, and billions of clients must similarly update their networking libraries, browsers, and other applications. But we have a good news that all the modern browser are already supporting HTTP/2 so no need to upgrade them. Also, most of the modern browsers use efficient background update mechanisms, which have already enabled HTTP/2 support with minimal intervention for a large proportion of existing users

HTTP/1.x will be around for at least another decade, and most servers and clients will have to support both HTTP/1.x and HTTP/2 standards. As a result, an HTTP/2 client and server must be able to discover and negotiate which protocol will be used prior to exchanging application data.

1) Over HTTP (un-secure)

A client that makes a request for an “http” URI without prior knowledge about support for HTTP/2 on the next hop uses the HTTP Upgrade mechanism (Section 6.7 of [RFC7230]). The client does so by making an HTTP/1.1 request that includes an Upgrade header field with the “h2c” token (h2c stands for HTTP/2 cleartext). Such an HTTP/1.1 request MUST include exactly one HTTP2-Settings header field.

For example:

GET / HTTP/1.1

Host: server.example.com

Connection: Upgrade, HTTP2-Settings

Upgrade: h2c

HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>

If the server that does NOT support HTTP/2 you will see something like this: (note there is no “Upgrade” header present in the server response)

HTTP/1.1 200 OK

Content-Length: 243

Content-Type: text/html

…

A server MUST ignore an “h2” token in an Upgrade header field, as “h2” implies HTTP/2 over TLS, which is instead negotiated differently as explained below.

A server that supports HTTP/2 accepts the upgrade and replies with a with a 101 status code (Switching Protocols) response. After the empty line that terminates the 101 response, the server can begin sending HTTP/2 frames. These frames MUST include a response to the request that initiated the upgrade.

For example:

HTTP/1.1 101 Switching Protocols

Connection: Upgrade

Upgrade: h2c

[ HTTP/2 connection …

2) Over HTTPS (secure)

A client that makes a request to an “https” URI uses TLS [TLS12] with the application-layer protocol negotiation (ALPN) extension [TLS-ALPN].

HTTP/2 over TLS uses the “h2” protocol identifier (the “h2c” protocol identifier MUST NOT be sent by a client or selected by a server; the “h2c” protocol identifier describes a protocol that does not use TLS).

The ALPN extension seeks to avoid an additional network round-trip by bundling the protocol negotiation with the exchange of hello messages. As part of the initial request (ClientHello), the client provides a list of protocols which it supports. The server then selects a protocol from that list and sends that selection back to the client along with its part of the TLS handshake (ServerHello). For previously established connections, the protocol selection can be negotiated over an abbreviated handshake.
With HTTP/2, all of the content from a single host can be served over a single connection. This eliminates not only the need to open and close of each additional connection, but also the need for an additional TLS handshake per connection, which translates in increased performance.

How to test HTTP/2 via command line?

Use this command: curl — http2.