Chapter12

• HTTP 2.0 introduced a new form of encapsulation which provides more efficient use of network resources and reduced perception of latency by allowing header field compression and multiple concurrent messages on the same connection.

Binary Framing Layer

At the core of the HTTP 2.0 enhancements it the HTTP Binary Framing Layer, which dictates how HTTP messages are encapsulated and transmitted between client and server. The “layer” refers to a design choice to introduce a new mechanism between the socket interface and the higher HTTP API exposed to the application. HTTP 1.x messages are new-line delimited. All HTTP 2.0 communication is split into smaller messages and frames, each of which is encoded in binary format.

Streams, Messages, and frames

HTTP 2.0 introduced some new terminology. Let’s go over that now.

• Stream = a bidirectional flow of bytes within an established HTTP 2.0 connection. All communication is performed within a single TCP connection. Each string has a unique integer identifier.
• Message = a complete sequence of frames that map to a logical message. The message is a logical HTTP message, such as a request or response.
• Frame = The smallest unit of HTTP communication, each containing a frame header, which at a minimum identifies to which stream the frame belongs. Frames carry specific types of data, such as headers, payloads, etc.

TCP Connection
------------------------------------------------------------------------------------------------------------------------------------------
Stream 1:
==============================================================              ==============================================================
Message: Frame[<Header>] Frame[<Payload>]                                   Message: Frame[<Header>] Frame[<Payload>]
==============================================================              ==============================================================

Stream 2:
==============================================================              ==============================================================
Message: Frame[<Header>] Frame[<Payload>]                                   Message: Frame[<Header>] Frame[<Payload>]                                   
==============================================================              ==============================================================
------------------------------------------------------------------------------------------------------------------------------------------

This model provides request and response multiplexing, in which the client can be transmitting frames to the server, and at the same time the server can be transmitting frames to the client. All within a single TCP connection. This essentially eliminates the head-of-line blocking problem!

Server Push

HTTP 2.0 also introduces Server Push. With server push, a client may send a single request for a resource, and the server can then send multiple responses back for resources that it knows the client will need. Why would we ever need this? A web page/app consists of multiple resources, all of which are discovered by the client while examining the document provided by the server. If the server knows the client is going to need those additional resources, it can just send them without the client actually requesting them. What if the client doesn’t want these additional resources? The client has the option to deny the resource being sent by the server. This process is implemented via a “Push Promise”. All server pushes are initiated with a Push Promise, which signals the servers intent to push resources to the client. The Push Promise frame only contains the HTTP headers of the promised resource. Once the client receives the promise, it has the option to decline the stream if it wants to (i.e. if the resource is already in the local client cache).

Apache’s MOD_SPDY mod looks for an X-ASSOCIATED-CONTENT header, which lists the resources to be pushed. The server can also just parse the document and infer the resources to be pushed. The strategy for implementing server push is not defined in the RFC, and is left up to the developer.

Header compression

Each HTTP 1.x transfer carries headers with it that can consume anywhere from 300-800 bytes of overhead per request, and kilobytes more if cookies are required. To reduce this overhead, HTTP 2.0 introduced header compression.

• Instead of transmitting the same data on each request and response, HTTP 2.0 uses “header tables” on both the client and server to keep track of previously sent key-value pairs
• Header tables persist for the lifetime of the HTTP 2.0 connection and can be incrementally updated
• Key-value pairs can be added or replaced

The key-value pairs for some headers like “method” and “scheme” rarely change during a connection, so a second request within the connection will not need to send these headers, saving several hundred bytes of data.