SPDY
2 likes3,301 views
SPDY was created by Google in 2009 to speed up web content delivery. It aims to reduce page load times by 50% by allowing multiple concurrent HTTP requests over a single TCP connection using features like request multiplexing, prioritization, and header compression. Some implementations of SPDY include Chrome, Firefox, and Amazon Kindle Fire. While it provides benefits, SPDY may not completely replace HTTP due to limitations like preventing single header extraction and potential for wasted server resources.
More Related Content
What's hot (20)
Similar to SPDY (20)
More from Daniel Stenberg (20)
Recently uploaded (20)
SPDY
- 1. SPDY
- 2. Daniel Stenberg ● Free Software ● Network hacker ● Embedded developer ● Consultant Email: daniel@haxx.se Twitter: @bagder Web: daniel.haxx.se Blog: daniel.haxx.se/blog
- 3. network and protocols ● created curl ● lead cares and libssh2 ● participate within IETF's HTTPbis, ftpext2, httpstate, hybi and more
- 4. Agenda ● Why SPDY ● Alternatives ● Goals ● can TCP improve? ● Who makes SPDY ● SPDY for curl ● Basic features ● Future ● Some Numbers ● Critiques ● Implementations
- 5. Questions? ● interrupt! ● comment! ● remark!
- 6. Why SPDY Growing HTTP requests – ● uncompressed headers ● Mozilla bug ● HTTP pipelining problems 264354 open ● Desire for multiple simultaneous transfers since Oct 2004 ● TCP 3way handshake ● TCP slow start ● Clientonly initiated requests ● HTTP has Optional compression
- 7. Goals ● 50% reduction in page load time ● minimize deployment complexity – done over TCP ● avoid the need for any changes to content ● allow many concurrent HTTP requests over a single TCP session ● reduce bandwidth use ● make TLS the underlying transport protocol
- 8. Who makes SPDY ● Created by Google in 2009 ● Pioneered in Chrome ● Discussed in the open ● Several independent implementations
- 9. Basic features ● Multiplexed streams ● Request prioritization ● HTTP header compression ● Serverinitiated streams
- 10. Multiplexed streams Single TCP
- 11. Multiple streams ● Cheap to create new ● Amount limit can be set by peer but it is unlimited by default ● Perstream flowcontrol (hello SCTP!)
- 12. Request prioritization ● Each stream has a 07 priority ● sender and recipient SHOULD use besteffort to process streams in prio order
- 13. HTTP header compression ● zlib compression ● prepopulated compression dictionary ● request headers: ~88% reduction ● response headers: ~85% reduction
- 14. Some Google numbers ● 25 of the "top 100" websites ● simulated home network connections ● 1% packet loss ● speedups over HTTP of 27% 60% in page load time over plain TCP (without SSL) ● and 39% 55% over SSL
- 15. Critiques ● SSL makes hard to debug and prevents use in some schools and companies ● header compression prevents single header extraction, makes adding headers expensive adds memory use per connection ● server push is potentially wasteful when contents already cached
- 16. Some implementations ● Chrome ● Firefox ● Amazon Kindle Fire ● more!
- 17. Alternative paths ● Waka 2002 ● HTTPMPLEX 2008 ● HTTP pipelining with several TCP connections ● SCTP ● SSH? ● MPTCP
- 18. TCP initial congestion Window ● ICW is 4K today ● ICW 10K: “average latency of HTTP responses improved by approximately 10%” ● “compounding HTTP pipelining with increasing the ICW size can lead to reduction in page load times by up to 80%” Yahoo!
- 19. TCP Fast Open ● IETF ID ● transfer data in SYN and SYNACK ● 1 RTT savings on 35% of HTTP requests (1040% have 400+ms RTT) ● Cookie to mitigate security vulnerabilities
- 20. SPDY for curl? ● SPDY is here to speed up the web ● curl's supposed to be speedy ● SPDY fits the spirit of curl ● multi interface, appear as separate use the same ● libspdy
- 21. the Future ● will SPDY replace HTTP? ● will there be a HTTP 2.0? websockets etc pushes it further away ● will there be a TCP replacement?
- 22. Summary ● SPDY speeds up the web ● There's no viable alternatives ● It will not replace HTTP within a foreseeable future
- 24. SPDY
- 25. Daniel Stenberg ● Free Software ● Network hacker ● Embedded developer ● Consultant Email: daniel@haxx.se Twitter: @bagder Web: daniel.haxx.se Blog: daniel.haxx.se/blog
- 26. network and protocols ● created curl ● lead cares and libssh2 ● participate within IETF's HTTPbis, ftpext2, httpstate, hybi and more
- 27. Agenda ● Why SPDY ● Alternatives ● Goals ● can TCP improve? ● Who makes SPDY ● SPDY for curl ● Basic features ● Future ● Some Numbers ● Critiques ● Implementations
- 28. Questions? ● interrupt! ● comment! ● remark!
- 29. Why SPDY Growing HTTP requests – ● uncompressed headers ● Mozilla bug ● HTTP pipelining problems 264354 open ● Desire for multiple simultaneous transfers since Oct 2004 ● TCP 3way handshake ● TCP slow start ● Clientonly initiated requests ● HTTP has Optional compression
- 30. Goals ● 50% reduction in page load time ● minimize deployment complexity – done over TCP ● avoid the need for any changes to content ● allow many concurrent HTTP requests over a single TCP session ● reduce bandwidth use ● make TLS the underlying transport protocol
- 31. Who makes SPDY ● Created by Google in 2009 ● Pioneered in Chrome ● Discussed in the open ● Several independent implementations
- 32. Basic features ● Multiplexed streams ● Request prioritization ● HTTP header compression ● Serverinitiated streams
- 33. Multiplexed streams Single TCP
- 34. Multiple streams ● Cheap to create new ● Amount limit can be set by peer but it is unlimited by default ● Perstream flowcontrol (hello SCTP!)
- 35. Request prioritization ● Each stream has a 07 priority ● sender and recipient SHOULD use besteffort to process streams in prio order
- 36. HTTP header compression ● zlib compression ● prepopulated compression dictionary ● request headers: ~88% reduction ● response headers: ~85% reduction
- 37. Some Google numbers ● 25 of the "top 100" websites ● simulated home network connections ● 1% packet loss ● speedups over HTTP of 27% 60% in page load time over plain TCP (without SSL) ● and 39% 55% over SSL
- 38. Critiques ● SSL makes hard to debug and prevents use in some schools and companies ● header compression prevents single header extraction, makes adding headers expensive adds memory use per connection ● server push is potentially wasteful when contents already cached
- 39. Some implementations ● Chrome ● Firefox ● Amazon Kindle Fire ● more!
- 40. Alternative paths ● Waka 2002 ● HTTPMPLEX 2008 ● HTTP pipelining with several TCP connections ● SCTP ● SSH? ● MPTCP
- 41. TCP initial congestion Window ● ICW is 4K today ● ICW 10K: “average latency of HTTP responses improved by approximately 10%” ● “compounding HTTP pipelining with increasing the ICW size can lead to reduction in page load times by up to 80%” Yahoo!
- 42. TCP Fast Open ● IETF ID ● transfer data in SYN and SYNACK ● 1 RTT savings on 35% of HTTP requests (1040% have 400+ms RTT) ● Cookie to mitigate security vulnerabilities
- 43. SPDY for curl? ● SPDY is here to speed up the web ● curl's supposed to be speedy ● SPDY fits the spirit of curl ● multi interface, appear as separate use the same ● libspdy
- 44. the Future ● will SPDY replace HTTP? ● will there be a HTTP 2.0? websockets etc pushes it further away ● will there be a TCP replacement?
- 45. Summary ● SPDY speeds up the web ● There's no viable alternatives ● It will not replace HTTP within a foreseeable future