˲ Inlined assets cannot be cached individually and inflate the parent document. A common practice of inlining
small images also inflates their size by
more than 30% via base64 encoding
and breaks request prioritization in the
browser—typically, images are fetched
with lower priority by the browser to accelerate page construction.
In short, many of the workarounds
have serious negative performance
implications. Web developers should
not have to worry about concatenating
files, spiriting images, inlining assets,
or domain sharding. All of these techniques are stopgap workarounds for
limitations of the HTTP 1. 1 protocol.
Hence, HTTP 2.0.
httP 2.0 Design and
Developing a major revision of a protocol underlying all Web communication is a nontrivial task requiring a lot
of careful thought, experimentation,
and coordination. As such, it is important to define a clear technical charter
and, arguably even more importantly,
define the boundaries of the project.
The intent is not to overhaul every detail of the protocol but to make meaningful though incremental progress to
improve Web performance.
With that, the HTTPbis Working
Group charter6 for HTTP 2.0 is scoped
˲ Substantially and measurably improve end-user-perceived latency in
most cases over HTTP 1. 1 using TCP.
˲Address the HOL (head-of-line)
blocking problem in HT TP.
˲ Do not require multiple connections to a server to enable parallelism,
thus improving its use of TCP, especially regarding congestion control.
˲ Retain the semantics of HTTP 1. 1,
leveraging existing documentation,
including (but not limited to) HTTP
methods, status codes, URIs, and
where appropriate, header fields.
˲ Clearly define how HTTP 2.0 interacts with HTTP 1.x, especially in intermediaries.
˲ Clearly identify any new extensibility points and policy for their appropriate use.
To deliver on these goals HTTP 2.0
introduces a new layering mechanism
onto TCP, which addresses the well-
known performance limitations of
HTTP 1.x. The application semantics
of HTTP remain untouched, and no
changes are being made to the core
concepts such as HTTP methods, sta-
tus codes, URIs, and header fields—
these changes are explicitly out of
scope. With that in mind, let’s take a
look “under the hood” of HTTP 2.0.
Request and response multiplex-
ing. At the core of all HTTP 2.0’s per-
formance enhancements is the new
binary framing layer (see Figure 2),
which dictates how HTTP messages
are encapsulated and transferred be-
tween the client and server. HTTP se-
mantics such as verbs, methods, and
headers are unaffected, but the way
they are encoded while in transit is
With HTTP 1.x, if the client wants
to make multiple parallel requests to
improve performance, then multiple
TCP connections are required. This
behavior is a direct consequence of the
newline-delimited plaintext HTTP 1.x
protocol, which ensures only one re-
sponse at a time can be delivered per
connection—worse, this also results
in HOL blocking and inefficient use of
the underlying TCP connection.
The new binary framing layer in
HTTP 2.0 removes these limitations
and enables full request and response
multiplexing. The following HTTP 2.0
figure 1. With 56ms Rtt, fetching two files takes approximately 228ms, with 80% of that
time in network latency.
GE T /html
S YN ACK 28 ms
0 ms S YN
server processing: 40 ms
HTML response 124 ms
GE T /css 152 ms
server processing: 20 ms
CSS response 200 ms
TCP connection #1, Request #1-2: HTTP + CSS
close connection 228 ms
figure 2. httP 2.0 binary framing.
Application (HTTP 2.0)
POST /upload HTTP/1.1
HT TP 2.0
H TTP 1. 1