the resource allocation is performed
between multiple streams. To address this, HTTP 2.0 provides a simple
mechanism for stream and connection flow control:
˲Flow control is hop-by-hop, not
˲ Flow control is based on window
update frames: the receiver advertises how many bytes of DATA-frame
payload it is prepared to receive on a
stream and for the entire connection.
˲ Flow-control window size is updated via a WINDOW_UPDATE frame
that specifies the stream ID and the
window increment value.
˲Flow control is directional—the
receiver may choose to set any window
size it desires for each stream and for
the entire connection.
˲ Flow control can be disabled by a
As experience with TCP shows, flow
control is both an art and a science.
Research on better algorithms and
implementation improvements are
continuing to this day. With that in
mind, HTTP 2.0 does not mandate any
specific approach. Instead, it simply
provides the necessary tools to implement such an algorithm—a great area
for further research and optimization.
Efficient HTTP 2.0 upgrade and
discovery. Though there are a lot more
technical and implementation details,
this whirlwind tour of HTTP 2.0 has
covered the highlights: binary framing, multiplexing, prioritization, server push, header compression, and flow
control. Combined, these features
will deliver significant performance
improvements on both the client and
Having said that, there is one more
minor detail: how does one deploy a
major revision of the HTTP protocol?
The switch to HTTP 2.0 cannot happen
overnight. Millions of servers must be
updated to use the new binary framing
protocol, and billions of clients must
similarly update their browsers and
The good news is that most mod-
ern browsers use efficient background
update mechanisms, which will en-
able HTTP 2.0 support quickly and
with minimal intervention for a large
portion of existing users. Despite this,
some users will be stuck with older
browsers, and servers and intermedi-
HTTP 2.0 is that this workflow can now
move out of the application and into
the HTTP protocol itself, which offers
important benefits: pushed resources
can be cached by the client, declined
by the client, reused across different
pages, and prioritized by the server.
In effect, server push makes obsolete most of the cases where inlining is
used in HTTP 1.x.
Header compression. Each HTTP
transfer carries a set of headers used
to describe the transferred resource.
In HTTP 1.x, this metadata is always
sent as plaintext and typically adds
anywhere from 500 to 800 bytes of
overhead per request, and often much
more if HTTP cookies are required.
To reduce this overhead and improve
performance, HTTP 2.0 compresses
header metadata: 8
˲ Instead of retransmitting the same
data on each request and response,
HTTP 2.0 uses header tables on both
the client and server to track and store
previously sent header key-value pairs.
˲ Header tables persist for the entire HTTP 2.0 connection and are incrementally updated both by the client
˲ Each new header key-value pair is
either appended to the existing table
or replaces a previous value in the table.
As a result, both sides of the HTTP
2.0 connection know which headers
have been sent, and their previous values, which allows a new set of headers
to be coded as a simple difference (see
Figure 7) from the previous set.
Common key-value pairs that rarely
change throughout the lifetime of a
connection (for example, user-agent,
accept header, and so on), need to
be transmitted only once. In fact, if
no headers change between requests
(for example, a polling request for
the same resource), then the header-encoding overhead is zero bytes—all
headers are automatically inherited
from the previous request.
Flow control. Multiplexing multiple streams over the same TCP connection introduces contention for
shared bandwidth resources. Stream
priorities can help determine the relative order of delivery, but priorities
alone are insufficient to control how
figure 7. Differential encoding of httP 2.0 headers.
Mozilla/5.0 … user-agent
Mozilla/5.0 … user-agent
HEADERS frame (Stream 1 )
user-agent: Mozilla/5.0 ...
HEADERS frame (Stream 3 )
Request #1 Request #2
figure 8. httP upgrade mechanism.
GET /page HTTP/1.1
Connection: Upgrade, HTTP2-Settings
HTTP2-Settings: (SETTINGS payload)
HTTP/1.1 200 OK
(... HTTP 1. 1 response ...)
HTTP/1.1 101 Switching Protocols
(... HTTP 2.0 response ...)