SPDY Talk
Upcoming SlideShare
Loading in...5
×
 

SPDY Talk

on

  • 1,824 views

 

Statistics

Views

Total Views
1,824
Views on SlideShare
1,813
Embed Views
11

Actions

Likes
1
Downloads
15
Comments
0

3 Embeds 11

http://www.linkedin.com 7
http://blaze.apphb.com 3
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

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
  • - new TCP connection is more expensive then old TCP connection - TCP congestion prevents internet from collapsing ( starts with small packets and increases on each RT )  - helps determining bandwidth of network - 
  • - 4 subdomains x 6 connections per domain = 24 simultaneous connections - 24 vs 100  - connection warming: what is we do not use pre-warmed connection? - there is a lot of overhead in http world
  • - silently implemented ( oops I did it again)
  • - TCP layer could been extended , but Application layer had too severe problems
  • - less RTs

SPDY Talk SPDY Talk Presentation Transcript

  •   Tech Talks @Rosenstraße Bojan Babic bojan.babic@groupon.de @bojanbabic
  • SPDYArchitecture of real-time web
  • HTTP/1.0 
  •  • new header introduced: Keep-alive• it has been adopted by community • default  in next version of HTTP
  • HTTP/1.1- RFC 2616: HTTP/1.1- draft 1998- release June 1999
  • Pipelining- non-idempotent connections 
  • Yahoo! 
  • Apple circa 1997 
  • Amazon
  • eBay 
  • Google 
  • Networking layer 
  • TCP Handshake 
  • Fast Forward 
  • from Alice in Chains
  • to P-P-P-Poker Face  
  • Intrawebz todayIn order page to load today on average:  • 44 resources • 7 hosts • 320KB  • ~66% of compressed ( 90% in Alexa top 1000 ) • RTT 50-500ms • number of connections to load  http://www.groupon.de - 83  o facebook 75 o google+ 64 o NYT 84 • more more connections 
  • Still• Expensive to make client - server connection ( TCP  congestion aka TCP slow start)• One connection at time and responses sequentially ( Keep- alive doesnt work )• snippet from RFC     "server MUST send its responses to thoserequests in the same order that the requestswere received"• even pipeline
  • Still Dreclient: -> GET /A HTTP/1.1client: -> GET /B HTTP/1.1 client: -> GET /C HTTP/1.1server: <- RESPONSE A: 200 OKserver: <- RESPONSE B: 200 OKserver: <- RESPONSE C: 200 OK • what if B is extremely large?  • what if C is ready before A and B? • parallel request, multiplexing ? pipelining (bad idea RFC)  • Requests only triggered by clients ( stocks, chat, weather ) • Error 500 response: what does it really mean ( gateway  issue, process crashed ... )   • more downsides? anyone? 
  • Page Load vs Bandwidth
  • Http - current state - tricks• prefetch DNS• work around limitations by enhancing policy within browser     (increase number of connections per domain) o enhance http limits in next versions by increasing number  of threads allowed per host ( 2, 4, 6 ...) • connection warming ( make request before it has been  sent , in order to remove handshaking out of way )• server push -  comet, channel, websocket are long lived  gets ( a lot of overhead ) 
  • Solutions (kinda) • pipelining ( doesnt really work ) o all browsers turn it off by default ( except Opera ) o hard to debug  o RFC• connection sharding ( in order to involve more threads from  browser ) o img1.groupon.com, img2.groupon.com• inlining css and js/ css sprites•  embedded images in data url 
  • SPDY:// 
  • Finally - SPDY ( HTTP/2.0?)• SPDY attempts to be efficient by using the network more intelligently• HTTP compatible• Created by Big G• Chrome: A/B testing 95% spdy 5% http• Google services • Endorsed by Firefox ( FF11 )• Used on Amazon Fire as protocol for their split architecture
  • chrome://net-internals/#spdy 
  • gmail POC  "Figures dont lie, but liars can figure"Chrome: loaded 2.65s 305KFirefox: loaded 5.5s 1.6M
  • SPDY under the hood• built on top of SSL but wraps http ( GET/POST remain the  same ) • adds session layer on top os SSL that allow MX
  • SPDY features• each request assigned stream-id• mandatory compression: headers compression is mandatory o most of headers do not change so they are predefined  and mapped in browser - only 3B are sent• connection multiplexing  o less connections  o less packets • uses SSL - finally internet secure (firesheep)• response in order which makes sense for server • server push ( even IDs server vs client request odd IDs) • prioritized request ( stylesheet, viewable images ... )• non-idempotent requests supported
  • SPDY features cnt• domain desharding by default o one connection per domain leaving cwnd 6 time smaller  compared to http o no dns lookup• reduce total amount of packages• reduce number of RT• on closed connection SPDY sends full report ( GOAWAY  FRAME ) which request have been processed • increased bandwidth utilization but speed to light did not  change with spdy (page load time vs RTT, RTT vs  bandwidth)• OVERALL : send fewer bytes using fewer connections 
  • Why SSL? • Why not port 80? Extend http handshake to at least one  more RT • Why not anther port? By default firewalls close other ports,  problem upgrading configs
  • Why SSL? part 2• Meantime in Web Sockets team: measuring package lost  over non-http protocol using following ports: o port 80 : 65% success rate ( "transparent" proxies - they  do mess with our data ) o port 6198: 86% success rate o port 443: 95% success rate ( encrypted data goes thru  firewalls )• Data loss pretty low
  • Why SSL? part 3• SSL is sloooow• Really? faster CPUs• TLS increase size of payload up to 2-3%, buut SDPY  compresses headers• real world data by Google: o spdy-no-ssl vs http: for 1-2% packet loss 41-47% speed  increase o spdy vs http: ~40% improvement o spdy vs https: 15,3% improvement
  • SPDY multiplexing
  • SPDY compression• avg headers size from 658B to 59B• dictionary of common headers: o Content-Type o User-Agent o encoding o Date o ...• Do not transfer headers just dict values• reduce upload size• reduce download size
  • SPDY lab results • 77% of requests reduced 90% in size • 94% of requests reduced 80% in size • upstream redundant headers 
  • How to be ready for SPDY?• no changes from developer side• changes on client side ( already done ... )• additional header recognition  o server push X-Associated-Content• changes on server side  o mod_spdy ( apache ) o Netty 3.3.1( twitter team contribution ) o spdy for node.js server o spdy google server ( to be open sourced )
  •   o nginx need to be rewritten to be ready for spdy
  •  • HTTP -> SPDY gateways  o comercial CDNs: cotendo, strange loop networks
  • SPDY Criticism• not standard it is draft • SSL poor fit for hierarchical caching • debugging tools not ready at moment (being  developed)
  • SPDY Criticism more• Next Protocol Negotiation  o http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00.html o extension to SSL  OK o part of SSL handshake no additional RTs OK o SSL initially requires more RTs
  • Plans for future • Spring 2012 FF and Google visit IEEFT o draft here: http://dev.chromium.org/spdy/spdy- protocol/spdy-protocol-draft1 • possible projects?- riak over spdy - map/reduce over spdy
  •   useful links: groups.google.com/group/spdy-dev https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00 http://www.chromium.org/spdy/spdy-protocol/spdy- protocol-draft2