• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
SPDY & HTTP2.0 & QUIC - #bpstudy 2013-08-28
 

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

on

  • 6,217 views

talk of SPDY, HTTP2, QUIC

talk of SPDY, HTTP2, QUIC
at #bpstudy 2013-08-28

Statistics

Views

Total Views
6,217
Views on SlideShare
3,609
Embed Views
2,608

Actions

Likes
27
Downloads
60
Comments
0

15 Embeds 2,608

http://connpass.com 1483
http://d.hatena.ne.jp 487
http://jxck.hatenablog.com 454
https://twitter.com 78
http://a3no.hatenablog.com 46
http://cloud.feedly.com 41
http://bpstudy.dev-connpass.owo3.net 7
http://www.feedspot.com 3
http://feedly.com 2
http://www.newsblur.com 2
http://www.getapi.ru 1
http://summary 1
http://newsblur.com 1
http://digg.com 1
http://www.hanrss.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • 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
    • spec and status HTTP ?
    • 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
    • spec and status SPDY ?
    • 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 <version=3, flags=0, length=102> (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 <version=3, flags=0, length=8> (last_good_stream_id=0)
    • SYN_STREAM FRAME
    • Multiplexing
    • 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.
    • Server Push
    • 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
    • history and status HTTP/2.0?
    • 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" 0x04 (literal header, substitution indexing, name index = 3) 0x03 (replaced entry index = 3) 0x0B (header value string length = 11) “/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" 0x04 (literal header, substitution indexing, name index = 3) 0x03 (replaced entry index = 3) 0x0B (header value string length = 10) “/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
    • spec and status QUIC ?
    • 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
    • Tools for dev Tools?
    • spdy-indicator ● chrome, firefox, opera ● supports ○ spdy/2 ○ spdy/3 ○ quic
    • chrome://net-internals
    • 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
    • anyone ? Q & A
    • thanks :) END