HTTP/2

Overview

Version 2 of the HTTP protocol is an emerging technology. All HTTP caching semantics described so far are still intact. Major changes include:

• Multiplexing a single TCP connection into streams (see below) to perform multiple resource deliveries simultaneously.
• A response status code 103 „Early Hints“ that can provide preconnecting, preloading and prefetching information to a client early during the response phase and can be followed by an additional final status code of the response later on, for example 200 „OK“.

Note that the „early hints“ workflow, facing slow HTTP/2 adoption rate and due to demand by popular web applications, has been back-ported to HTTP version 1.1 in [RFC 8297]. However, popular webserver software such as „Apache“ does not implement „early hints“ in HTTP version 1.1.

Multiplexing and Streams

Multiplexing is the replacement for pipelining in HTTP version 2. The TCP connection between an HTTP/2 client and server is primarily managed by a protocol that defines frames which are chunks of communicated data. This resembles chunked encoding over a pipelining connection in HTTP 1.1, but the frame management happens on a lower level thatn the headers and bodies of requests and responses. Frames have a binary header and a length that server and client agree upon.

A series of frames can constitute a „stream“ over which a series of requests and responses can be accomlished. Multiple streams can be multiplexed onto the same TCP connection.

Streams can have priorities, implying the distribution of bandwidth of a connection amongst concurrent, competing streams. The priorities are negotiated between client and server, and a stream priority can also be renegotiated during the runtime of a stream.

Proxy Connections

[RFC 7540] section 9.1 mandates that clients should limit connections to a configured proxy server to one. Subsection 9.1.1 mandates that clients should reuse that single connection for all resource requests performed via that proxy. The requests are to be multiplexed using streams.

In practice, many web proxies have no sufficient support for user-facing HTTP version 2 yet, and some popular user agents will fall back to HTTP version 1.1 connections to their configured proxies.

Server Push

To reduce loading time or to quickly make available rapidly updated information, HTTP version 2 offers a new feature called „server push“:

• A HTTP client opens a connection to a server using protocol version 2. The connection is persistent.
• Until the connection is closed, the server can initiatively offer resources to the client by sending a „push promise“.
• The server will follow the push promise by the actual push of a resource on the same multiplexed connection.
• Having evaluated the promise, a client, having validated the offered resource with privatly cached versions, can choose to abort the incoming push by sending a stream-level message to the server that it refuses or cancels the stream. The server will then abort the ongoing push.

The server push is a new paradigm for HTTP client-server-communication, and several aspects have to be considered when extending existing implementations with support for the new feature set. Some of these aspects are:

• How to validate the promised resource with the private cache to be able to refuse a push in order to reduce network load,
• Ho to deal with interleaving of personalized and shared resources on the same multiplexed connection, especially if they are pushed proactively by the server.