0
     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 Al...
Still• Expensive to make client - server connection ( TCP   congestion aka TCP slow start)• One connection at time and res...
Still Dreclient: -> GET /A HTTP/1.1client: -> GET /B HTTP/1.1 client: -> GET /C HTTP/1.1server: <- RESPONSE A: 200 OKserve...
Page Load vs Bandwidth
Http - current state - tricks• prefetch DNS• work around limitations by enhancing policy within browser      (increase num...
Solutions (kinda) • pipelining ( doesnt really work )   o all browsers turn it off by default ( except Opera )   o hard to...
SPDY:// 
Finally - SPDY ( HTTP/2.0?)• SPDY attempts to be efficient by using the network more intelligently• HTTP compatible•   Cre...
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 ...
SPDY features• each request assigned stream-id• mandatory compression: headers compression is mandatory   o most of header...
SPDY features cnt• domain desharding by default   o one connection per domain leaving cwnd 6 time smaller      compared to...
Why SSL? • Why not port 80? Extend http handshake to at least one   more RT • Why not anther port? By default firewalls cl...
Why SSL? part 2• Meantime in Web Sockets team: measuring package lost   over non-http protocol using following ports:   o ...
Why SSL? part 3• SSL is sloooow• Really? faster CPUs• TLS increase size of payload up to 2-3%, buut SDPY   compresses head...
SPDY multiplexing
SPDY compression• avg headers size from 658B to 59B• dictionary of common headers:   o Content-Type   o User-Agent   o enc...
SPDY lab results   • 77% of requests reduced 90% in size   • 94% of requests reduced 80% in size   • upstream redundant he...
How to be ready for SPDY?• no changes from developer side• changes on client side ( already done ... )• additional header ...
     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 (be...
SPDY Criticism more• Next Protocol Negotiation   o http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00.html  o extens...
Plans for future • Spring 2012 FF and Google visit IEEFT     o draft here: http://dev.chromium.org/spdy/spdy-       protoc...
     useful links:    groups.google.com/group/spdy-dev    https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00    ...
SPDY Talk
Upcoming SlideShare
Loading in...5
×

SPDY Talk

1,788

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,788
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
18
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • - 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
  • Transcript of "SPDY Talk"

    1. 1.   Tech Talks @Rosenstraße Bojan Babic bojan.babic@groupon.de @bojanbabic
    2. 2. SPDYArchitecture of real-time web
    3. 3. HTTP/1.0 
    4. 4.  • new header introduced: Keep-alive• it has been adopted by community • default  in next version of HTTP
    5. 5. HTTP/1.1- RFC 2616: HTTP/1.1- draft 1998- release June 1999
    6. 6. Pipelining- non-idempotent connections 
    7. 7. Yahoo! 
    8. 8. Apple circa 1997 
    9. 9. Amazon
    10. 10. eBay 
    11. 11. Google 
    12. 12. Networking layer 
    13. 13. TCP Handshake 
    14. 14. Fast Forward 
    15. 15. from Alice in Chains
    16. 16. to P-P-P-Poker Face  
    17. 17. 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 
    18. 18. 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
    19. 19. 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? 
    20. 20. Page Load vs Bandwidth
    21. 21. 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 ) 
    22. 22. 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 
    23. 23. SPDY:// 
    24. 24. 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
    25. 25. chrome://net-internals/#spdy 
    26. 26. gmail POC  "Figures dont lie, but liars can figure"Chrome: loaded 2.65s 305KFirefox: loaded 5.5s 1.6M
    27. 27. 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
    28. 28. 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
    29. 29. 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 
    30. 30. 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
    31. 31. 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
    32. 32. 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
    33. 33. SPDY multiplexing
    34. 34. 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
    35. 35. SPDY lab results • 77% of requests reduced 90% in size • 94% of requests reduced 80% in size • upstream redundant headers 
    36. 36. 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 )
    37. 37.   o nginx need to be rewritten to be ready for spdy
    38. 38.  • HTTP -> SPDY gateways  o comercial CDNs: cotendo, strange loop networks
    39. 39. SPDY Criticism• not standard it is draft • SSL poor fit for hierarchical caching • debugging tools not ready at moment (being  developed)
    40. 40. 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
    41. 41. 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
    42. 42.   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
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×