HTTP/2 and QUICK protocols. Optimizing the Web stack for HTTP/2 era
Transcript of HTTP/2 and QUICK protocols. Optimizing the Web stack for HTTP/2 era
HTTP has been in use by the World-Wide Web global information initiative since 1990
Browser sends request to the server
Server responds
GET /index.html HTTP/1.1
HTTP/1.1 200 OK
Optional parts, like HTTP Pipelining
It is very latency sensitive
The specification is huge
HTTP 1.1 issues
and more...
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
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 size7
Using cookie-free domains8
Using <link> instead of @import9
Developers invented workarounds
Pack components into a multipart document (like email with attachments)
10
Developers invented workarounds
Using HTTP Upgrade
mechanismHTTP
How browser switches to HTTP/2
GET / HTTP/1.1 Host: server.example.com Connection: Upgrade, HTTP2-Settings Upgrade: h2c HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
HTTP/2 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
ONE connection to the server should be enough(not six connections per domain as most browsers do now)
HTTP/2 Features
Frame format
+-----------------------------------------------+ | Length (24) | +---------------+---------------+---------------+ | Type (8) | Flags (8) | +-+-------------+---------------+-------------------------------+ |R| Stream Identifier (31) | +=+=============================================================+ | Frame Payload (0...) ... +---------------------------------------------------------------+
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
SETTINGSConveys configuration parameters that affect how endpoints
communicate
Frame types
PUSH_PROMISEUsed to notify the peer endpoint in advance of streams the sender
intends to initiate
PINGMeasuring 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_UPDATEUsed to implement flow control on each individual stream or on the
entire connection.
CONTNUATION Used to continue a sequence of header block fragments
Stream priority
Each stream has priority
Specified by the client (browser)
Priority can be changed runtime
Header compression
HTTP/2 is stateless protocol too
The client still has to send data to the server
The headers in HTTP/2 are compressed
Header compression
StatefulOne compression context and one
decompression context is used for the entire connection
The algorithm is called HPACK (Header Compression for HTTP/2)
Server push
Server pre-emptively sends resources to a client,
in association with a previous client-initiated request
Browser implementations
Internet Explorer supports HTTP/2 from IE 11 on Windows 10 beta
Firefox has enabled HTTP/2 by default in version 34
Chrome supports HTTP/2, enabled by default. Chrome Canary supports identifying servers using the latest draft (h2-17)
Opera supports HTTP/2 by default
(does someone know anything about Safari?)
Currently only HTTP/2 over TLS is implemented in all browsers
QUIC Features
Natural extension of SPDY and HTTP/2 research
Multiplexing transport protocol
Runs on top of UDP
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
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
Goal: 0-RTT (round-trip time) connectivity overhead
Has all the benefits of SPDY and HTTP/2
QUIC Features
but...
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
QUIC Features
100 ms
0 ms RTT Repeat connection
New connection
QUIC TCP + TLS
300 ms
200 ms RTT Repeat connection
New connection
QUIC Encryption
Comparable to TLS, with more efficient handshake
Replay attack and IP Spoofing protection
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
Minimizing JavaScript, CSS and HTML files1
Removing redundant data from images2
Optimize Critical Path CSS3
Optimize the content sent to the brower
Removing the CSS which is not needed on the page4
Specifying ETag and setting far future expires headers5
Using HTML 5 offline to store already downloaded files6
Optimize the content sent to the brower
Set the value of TCP’s initial cwnd to 10 segments (IW10)1
Disable Slow-Start Restart after idle2
Check and enable if needed Window Scaling3
Optimize the content sent to the browser
Consider to use TCP Fast Open (TFO)4
Joining files1
Domain sharding2
Resource inlining3
Remove some "optimizations"
Image sprites4
Combo services5
Cookie free domains6