HTTP 2.0 and QUIC
protocols of the (near)
future
@ipeychev
Slide 2
Slide 2 text
Why a new version of
HTTP protocol?
2.0
Slide 3
Slide 3 text
HTTP is used by the World-Wide Web since 1990
Browser sends request to the server
Server responds
GET /index.html HTTP/1.1
HTTP/1.1 200 OK
Slide 4
Slide 4 text
The number of requests per page increases
HTTP Archive
Top 100 sites
data for
15.11.2010 - 1.10.2014
Slide 5
Slide 5 text
HTTP 1.1 has issues
Slide 6
Slide 6 text
Optional parts, like
HTTP Pipelining
It is very latency
sensitive
The specification
is huge
HTTP 1.1 issues
and more...
Slide 7
Slide 7 text
Latency kills and bandwidth is
not everything
Slide 8
Slide 8 text
Latency vs bandwidth
Ilya Grigorik
Developer Advocate, Google
Slide 9
Slide 9 text
What could be the solution?
Slide 10
Slide 10 text
HTTP pipelining?
WikipediA
The free Encyclopedia
Slide 11
Slide 11 text
HTTP pipelining
Slide 12
Slide 12 text
Why not HTTP Pipelining?
The server must send its responses in the same order that
requests were received
So the entire connection remains first-in-first-out (FIFO)
and Head-of-line (HOL) blocking can occur
and more, like buggy proxy servers
Slide 13
Slide 13 text
In most browsers HTTP pipelining is disabled
Or not implemented at all
Browsers achieve multiplexing by opening multiple connections
to servers
As a result...
Reducing cookie size
7
Using cookie-free domains
8
Using instead of @import
9
Developers invented workarounds
Slide 18
Slide 18 text
Pack components into a multipart document
(like email with attachments)
10
Developers invented workarounds
Slide 19
Slide 19 text
browser diet
Slide 20
Slide 20 text
No content
Slide 21
Slide 21 text
Got tired?
Slide 22
Slide 22 text
Welcome to
HTTP 2.0 and QUIC
Slide 23
Slide 23 text
HTTP 2.0 (draft 14)
Slide 24
Slide 24 text
HTTP 2.0 fixes issues in HTTP 1.1
without breaking the web
Slide 25
Slide 25 text
Using
HTTP Upgrade
mechanism
HTTP
How browser switches to HTTP 2.0
GET / HTTP/1.1
Host: server.example.com
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings:
Slide 26
Slide 26 text
HTTPS
How browser switches to HTTP 2.0
ALPN
Using
Application Layer
Protocol Negotiation
extension
Slide 27
Slide 27 text
HTTP 2.0 features
Slide 28
Slide 28 text
HTTP 2.0 Features
It is a binary protocol, not text one
Browser and server exchange frames
Each frame belongs to stream
Streams are multiplexed, with priorities
Server push
Slide 29
Slide 29 text
ONE connection to the server should be enough
(not six connections per domain as most browsers do now)
HTTP 2.0 Features
Frame types
DATA Convey arbitrary data associated with a stream
HEADERS Used to open a stream and carries name-value pairs
PRIORITY Specifies the sender-advised priority of a stream
RST_STREAM Allows abnormal termination of a stream
SETTINGS
Conveys configuration parameters that affect how endpoints
communicate
Slide 33
Slide 33 text
Frame types
PUSH_PROMISE
Used to notify the peer endpoint in advance of streams the sender
intends to initiate
PING
Measuring a minimal round-trip time from the sender; checks if a
connection is still alive
GOAWAY Informs the remote peer to stop creating streams on this connection
WINDOW_UPDATE
Used to implement flow control on each individual stream or on the
entire connection.
CONTNUATION Used to continue a sequence of header block fragments
Slide 34
Slide 34 text
Streams
Slide 35
Slide 35 text
Stream
Logical, bi-directional sequence of frames.
Slide 36
Slide 36 text
Streams
One single connection - multiple open streams.
Slide 37
Slide 37 text
Priorities and dependencies
Slide 38
Slide 38 text
Stream priority
Each stream has priority
Specified by the client (browser)
Priority can be changed runtime
Slide 39
Slide 39 text
Stream dependencies
A stream can depend on another one.
A
B C
D
Slide 40
Slide 40 text
Stream dependencies
A
B C
D
A stream can depend on another one.
Slide 41
Slide 41 text
Headers
Slide 42
Slide 42 text
Header compression
HTTP 2.0 is stateless protocol too
The client still has to send data to the server
The headers in HTTP 2.0 are compressed
Slide 43
Slide 43 text
Header compression
Stateful
Using a single compression context for the
entire connection
The algorithm is called HPACK (Header
Compression for HTTP/2)
Slide 44
Slide 44 text
Header compression
HPACK has been invented because
of attacks like CRIME and BREACH
Slide 45
Slide 45 text
Server push
(we did that for years)
Slide 46
Slide 46 text
Server push
Server pre-emptively sends resources to a client,
in association with a previous client-initiated
request
Slide 47
Slide 47 text
Server push
The client explicitly must allow it
A client cannot push
Slide 48
Slide 48 text
HTTP/2 rulez!
Slide 49
Slide 49 text
QUIC protocol
Slide 50
Slide 50 text
QUIC Features
Natural extension of SPDY/HTTP 2.0 research
Multiplexing transport protocol
Runs on top of UDP
Slide 51
Slide 51 text
Why not SCTP over DTLS?
After all, SCTP provides (among other things) stream
multiplexing
And DTLS provides SSL quality encryption and
authentication over a UDP stream
Slide 52
Slide 52 text
Why not SCTP over DTLS?
Mainly because roughly 4 round trips are needed to
establish an SCTP over DTLS connection
In contrast, the goal of QUIC is to perform a connection
establishment with zero RTT overhead
Slide 53
Slide 53 text
Goal: 0-RTT (round-trip time) connectivity
overhead
Has all the benefits of SPDY/HTTP 2.0
QUIC Features
but...
Slide 54
Slide 54 text
QUIC Features
No head-of-line blocking in QUIC!
Slide 55
Slide 55 text
QUIC Features
Delay of only one packet causes the entire set of
SPDY (aka HTTP/2) streams to pause.
(Since TCP only provides a single serialized stream interface)
In QUIC, when a single packet is lost,
only one stream is being delayed
Slide 56
Slide 56 text
QUIC Features
No head-of-line blocking in QUIC!
Slide 57
Slide 57 text
QUIC Features
100 ms
0 ms RTT
Repeat connection
New connection
QUIC TCP + TLS
300 ms
200 ms RTT
Repeat connection
New connection
Slide 58
Slide 58 text
QUIC Encryption
Comparable to TLS, with more efficient handshake
Replay attack and IP Spoofing protection
Slide 59
Slide 59 text
QUIC Forward error correction
Slide 60
Slide 60 text
QUIC Internet connections persistence
Communication channels are not defined by IP
+Port but by an ID
You leave a WiFi zone and entering a mobile one
but the connection continues
Slide 61
Slide 61 text
Demo time
Slide 62
Slide 62 text
No content
Slide 63
Slide 63 text
https://http2rulez.com
Open Source platform for testing different
optimization strategies for HTTP 2.0
Same content, served via HTTP, HTTPS, SPDY and
HTTP/2
(No QUIC endpoint yet)
View Page Load Time for each page
Slide 64
Slide 64 text
HTTPS Waterfall
HTTPS waterfall
Slide 65
Slide 65 text
HTTPS connection view
Slide 66
Slide 66 text
HTTP/2 waterfall without server push
Slide 67
Slide 67 text
HTTP/2 connection view without server push
Slide 68
Slide 68 text
HTTP/2 waterfall with server push
Slide 69
Slide 69 text
HTTP/2 connection view with server push
Slide 70
Slide 70 text
Wrap up
Slide 71
Slide 71 text
Wrap up
Remember the workarounds we do to speed up our
sites?
Slide 72
Slide 72 text
Wrap up
Ask yourself
Slide 73
Slide 73 text
Wrap up
How HTTP 2.0 will affect the way
YOU
develop and optimize Web applications?