SPDY & HTTP2.0 & QUIC - #bpstudy 2013-08-28

SPDY HTTP2 QUIC
2013/08/28
#bpstudy72

Jack
● id: Jxck
● github: Jxck
● twitter: jxck_
● about: http://jxck.io
● blog: http://d.hatena.ne.jp/jxck
● Love: music

http2cat
supports todays talk
http://jxck.io/labs/http2cat

History of HTTP
... HTTP/0.9
1996/ 5 HTTP/1.0 (RFC 1945)
1997/ 1 HTTP/1.1 (RFC 2068)
2009/11 SPDY/1
...
2011/ 9 WebSocket(RFC 6455)
2012/ 8 HTTP/2.0 start
2012/11 HTTP/2.0 (draft-00)
2013/ 7 HTTP/2.0 (draft-04)
2013/ 8 interop testing
2013/ 8 HTTP/2.0 (draft-06)

motivation
● Sharing Documents
● Over TCP
● Text Base Protocol
● Stateless
version
● HTTP/0.9
● HTTP/1.0
● HTTP/1.1
○ Keep-Alive
○ Pipelining
HTTP / 1.1

CLIENT SERVER
Req / Res on HTTP/1.1
Text Base Protocol
GET /index.html HTTP/1.1
Host: example.org
Accept: text/html
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 35
<!DOCTYPE html>
<title>hello</title>

over TCP (3-way-handshake)
3-way-handshake: Cost for Reliable

over TCP (Slow Start)
Increase Segment Size
for Congection Control

Keep-Alive & Pipelining
● Keep-Alive
○ Re-Use TCP Connection
● Pipelining
○ Send all Req before Res

HTTP ?
● Simple
○ text base, easy scaling etc
○ good for document sharing
○ but Good for Now ?
● now “Web” is
○ Plat Form (not only document sharing)
○ Ajax, WebSocket…
○ tons of JS, CSS, Images...
○ PC, Mobile, Tablet, TV, Game …
● needs
○ more speed
○ more efficiency
○ more secure

motivation
● multiplexing
● header compression
● reduce RTT
● etc
version
● spdy/1
● spdy/2 (nginx)
● spdy/3 (mod_spdy, jetty)
● spdy/3.1 (twitter)
● spdy/4a3 (google)
● spdy/4 (discussing)
about SPDY

SPDY / 3 core feature
● npn (tls extension)
○ only https
● 1 connection
○ controlable keep alive
● multiplexing
○ better pipelining
● compressed binary frame
○ smaller than text protocol
● server push
○ new idea

TLS-NPN (next protocol negotiation)

Compressed Binary Frame
SYN_STREAM
SYN_REPLY
RST_STREAM
SETTINGS
PING
GOAWAY
HEADERS
WINDOW_UPDATE
CREDENTIAL

SYN_STREAM frame
<version=3, flags=1, length=217>
(stream_id=1, assoc_stream_id=0, pri=3)
:host: localhost:3000
:method: GET
:path: /
:scheme: https
:version: HTTP/1.1
accept: */*
accept-encoding: gzip
SYN_REPLY frame
(stream_id=1)
:status: 200 OK
:version: HTTP/1.1
content-length: 37
Stream(spdy/3)
CLIENT SERVER
Request Header
Response Header
Stream Start

Stream(spdy/3)
CLIENT
Stream End
SERVER
DATA frame
(stream_id=1, flags=0, length=37)
<!DOCTYPE html>
<title>hello</title> Response Body
DATA frame
(stream_id=1, flags=1, length=0)
GOAWAY frame
(last_good_stream_id=0)

Server Push
// index.html
<html>
<script src=”a.js”
/>
<link rel=”b.css” />
<img src=”c.png” />
</html>
server pushes
a.js, b.css, c.png
while processing
index.html
pushed resources are
cached in browser
and cache hit when
browser need it.

SPDY
● Google’s Original Protocol
○ Google has both server & client
● Widely Deployed
○ twitter
○ facebook
○ LINE
● SPDY/4 discussing
○ websocket over spdy etc
● CRIME attack
○ disable header compression
○ need another compression

about HTTP2
● httpbis wg at IETF from 2012
● motivation
○ update HTTP/1.1
● version
○ draft-00 (copy of spdy/3)
○ ...
○ draft-03
○ draft-04 (interop test)
○ draft-05
○ draft-06 (2013/8/28 current)
○ ...
○ RFC XXXX (2014 spring? bit.ly/130oZrZ)

SPDY or HTTP2.0 ?
SPDY/3
SPDY/4
http2.0-00
http2.0-01
http2.0-06
http2.0
SPDY/n ??

specs
● working on github !
○ https://github.com/http2/http2-spec
● draft
○ http://tools.ietf.org/wg/httpbis/draft-ietf-httpbis-http2/
● current (2013/8/28)
○ http://tools.ietf.org/html/draft-ietf-httpbis-http2-06
● ML
○ http://lists.w3.org/Archives/Public/ietf-http-wg/
○ https://www.ietf.org/mailman/listinfo/http-devops (new)

HTTP/2.0 draft-06
● Multiplexing (same as spdy)
● Server Push (same idea as spdy)
● ALPN / Upgrade
● Binary Frames
● Header Compression

Starting HTTP2.0 (1/2 step)
● “http://”
○ Upgrade Header like websocket
● “https://”
○ ALPN (application layer protocol
negotiation)
○ not NPN like spdy
● Known Supported
○ prior knowledge from DNS or so
○ may immediately send http2.0 frame

TLS-ALPN(Application Layer protocol negotiation)

Starting HTTP2.0 (2/2 step)
● sending connection header
○ make sure peer supports http2.0
● with Magic Octets
505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
PRI * HTTP/2.0
rnrn
SM
rnrn
invalid
Method PRI
2 new line
for parser

Frame Type
● DATA
● HEADERS
● PRIORITY
● RST_STREAM
● SETTINGS
● PUSH_PROMISE
● PING
● GOAWAY
● WINDOW_UPDATE
● CONTINUATION
Changed from
SPDY/3

HEADERS & DATA frame
CLIENT SERVER
HEADERS(stream_id=1)
+ END_STREAM
+ END_HEADERS
:method = GET
:scheme = https
:host = example.org
:path = /index.html
accept = text/html
HEADERS(stream_id=1)
- END_STREAM
+ END_HEADERS
:status = 200
content-type = text/html
content-length = 35
DATA(stream_id=1)
+ END_STREAM
<!DOCTYPE html>
<title>hello</title>

Server Push(1)
CLIENT SERVER
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 123
{binary data}
PUSH_PROMISE (stream_id=1)
+ END_PUSH_PROMISE
Promised-Stream-ID=2
:method = GET
:scheme = https
:host = example.org
:path = /index.html
accept = text/html
HEADERS (stream_id=1)
+ END_STREAM
+ END_HEADERS
:method = GET
:scheme = https
:host = example.org
:path = /index.html
accept = text/html
PUSH
Request

Server Push(2)
CLIENT SERVER
Browser
Cache
DATA (stream_id=2)
+ END_STREAM
{binary data}
HEADERS (stream_id=2)
- END_STREAM
+ END_HEADERS
:status = 200
:path = /a.png
content-type = image/png
content-length = 123
PUSH
Respons

Server Push(2)
CLIENT SERVER
HEADERS　(stream_id=1)
- END_STREAM
+ END_HEADERS
:status = 200
content-type = text/html
content-length = 33
DATA (stream_id=1)
+ END_STREAM
<html>
<img src=”a.png”>
</html>
cache hit !!
Response

HPAC (header compression)
● HTTP Header
○ Text Base
○ Long Name
○ Send multiple time
● SPDY compression
○ CRIME
● HPAC
○ send diff
○ using binary
● HPAC component
○ Header Table
○ Reference Set

Header Table
Index Header Name Header Value
0 :scheme http
1 :scheme https
2 :host
3 :path /
4 :method GET
5 accept
6 accept-charset
7 accept-encoding
... ...
29 via
Index Header Name Header Value
0 :status 200
1 age
2 cache-control
3 content-length
4 content-type
5 date
6 etag
7 expires
... ...
29 www-authenticate
Request Header Table Response Header Table

Header Representation
● Indexed Header Representation
● Literal Header Representation
○ Literal Header without Indexing
○ Literal Header with Incremental Indexing
○ Literal Header with Substitution Indexing

HPAC example (1/3)
CLIENT SERVER
Use index 0
0x80 (indexed header, index = 0)
Use index 4
0x84 (indexed header, index = 4)
Use index 2
with replace "example.org"
0x03 (literal header, substitution indexing,
name index = 2)
0x02 (replaced entry index = 2)
0x0B (header value string length = 11)
“example.org”
Use index 3
with replace "/index.html"
name index = 3)
“/index.html”
0 :scheme http
1 :scheme https
2 :host exampl
e.com
3 :path /index.
html
4 :method GET
0 :scheme http
1 :scheme https
2 :host
3 :path /
4 :method GET
reference set
:scheme https
:host example.org
:path /index.html
:method GET
reference set
GET /index.html
50byte -> 30byte

HPAC example (2/3)
CLIENT SERVER
Use index 3
with replace "/client.js"
name index = 3)
“/client.js”
0 :scheme http
1 :scheme https
2 :host examp,
e.org
3 :path /client.js
4 :method GET
0 :scheme http
1 :scheme https
2 :host exampl
e.org
3 :path /inde.
html
4 :method GET
reference set
:scheme https
:host example.org
:path /client.js
:method GET
reference set
:scheme https
:host example.org
:path /index.html
:method GET
GET /client.js
49byte -> 13byte

HPAC example (3/3)
CLIENT SERVER
0 :scheme http
1 :scheme https
2 :host examp,
e.org
3 :path /index.
html
4 :method GET
0 :scheme http
1 :scheme https
2 :host example
.org
3 :path /client.js
4 :method GET
reference set
:scheme https
:host example.org
:path /client.js
:method GET
reference set
:scheme https
:host example.org
:path /client.js
:method GET
GET /client.js
49byte -> 0byte

implementations
● nghttp2 C
● http2-katana C#
● node-http2 NodeJS
● Mozilla C++
● http2-perl Perl
● iij-http2 NodeJS
● Akamai Ghost C++
● Chromium C++
● Hasan's GFE C++
● Twitter Java
see: https://github.com/http2/http2-spec/wiki/Implementations

QUIC ?
● SPDY over TCP has problem
○ 1 packet loss effects all streams
○ 3-way-handshake needs RTT
○ single congection winodw
● build reliable layer on UDP
○ packet loss dosen’t effects stream
○ less RTT
○ separate congection window
○ SSL layer
○ packet level error collection
● SPDY over QUIC
○ chrome canaly
○ www.google.com

QUIC resources
● docs, article
○ https://docs.google.
com/document/d/1RNHkx_VvKWyWg6Lr8SZ-
saqsQx7rFV-ev2jRFUoVD34/edit
○ http://blog.chromium.org/2013/06/experimenting-
with-quic.html?spref=tw&m=1
● ML
○ https://groups.google.com/a/chromium.
org/d/forum/proto-quic
● Source
○ https://code.google.
com/p/chromium/codesearch#chromium/src/net/quic
/&ct=rc&cd=1&q=quic&sq=package:chromium

more
http://d.hatena.ne.jp/Jxck/20130723/1374535593

spdy-indicator
● chrome, firefox, opera
● supports
○ spdy/2
○ spdy/3
○ quic

nghttp2 & spdylay
● C implementation library
● spdycat, nghttp
○ client cli tool
● spdyd, nghttpd
○ file server
● shrpx, nghttpdx
○ proxy
web frontend of nghttp2 & spdycat => http2cat

HTTP2Cat (https://jxck.io/labs/http2cat)

books
● High Performance Browser Networking
○ by Ilya Grigorik(Google)
● http://chimera.labs.oreilly.com/books/1230000000545

SPDY & HTTP2.0 & QUIC - #bpstudy 2013-08-28

Recommended

More Related Content

What's hot (19)

Viewers also liked (20)

Similar to SPDY & HTTP2.0 & QUIC - #bpstudy 2013-08-28 (20)

More from Jxck Jxck (20)

Recently uploaded (20)

SPDY & HTTP2.0 & QUIC - #bpstudy 2013-08-28