SPDY Talk
Download as PPT, PDF1 like2,134 views
Tech Talks @Rosenstraße discussed SPDY, a new protocol developed by Google to make web content delivery faster and more efficient than HTTP. SPDY uses many of HTTP's foundations but adds features like compression, multiplexing, and prioritization to reduce page load times. It is built on top of SSL for security and takes advantage of SSL's widespread support in firewalls. While still a draft, SPDY has shown promise in reducing page load times in tests. The talk covered the technical details of how SPDY works and potential issues like a lack of debugging tools.
SPDY Talk
- 3. HTTP/1.0
- 5. • new header introduced: Keep-alive • it has been adopted by community • default in next version of HTTP
- 8. Yahoo!
- 10. Amazon
- 11. eBay
- 12. Google
- 13. Networking layer
- 14. TCP Handshake
- 15. Fast Forward
- 18. Intrawebz today In 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
- 19. Still • Expensive to make client - server connection ( TCP congestion aka TCP slow start) • One connection at time and responses sequentially ( Keep- alive doesn't work ) • snippet from RFC "server MUST send its responses to those requests in the same order that the requests were received" • even pipeline
- 20. Still Dre client: -> GET /A HTTP/1.1 client: -> GET /B HTTP/1.1 client: -> GET /C HTTP/1.1 server: <- RESPONSE A: 200 OK server: <- RESPONSE B: 200 OK server: <- 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?
- 22. 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 )
- 23. Solutions (kinda) • pipelining ( doesn't 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
- 24. SPDY://
- 25. 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
- 27. gmail POC "Figures don't lie, but liars can figure" Chrome: loaded 2.65s 305K Firefox: loaded 5.5s 1.6M
- 28. 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
- 29. 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
- 30. 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
- 31. 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
- 32. 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
- 33. 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
- 35. 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
- 36. SPDY lab results • 77% of requests reduced 90% in size • 94% of requests reduced 80% in size • upstream redundant headers
- 37. 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 )
- 39. • HTTP -> SPDY gateways o comercial CDNs: cotendo, strange loop networks
- 40. SPDY Criticism • not standard it is draft • SSL poor fit for hierarchical caching • debugging tools not ready at moment (being developed)
- 41. 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
- 42. 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
Editor's Notes
- #20: - 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 -
- #23: - 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
- #26: - silently implemented ( oops I did it again)
- #29: - TCP layer could been extended , but Application layer had too severe problems
- #35: - less RTs