Embed Size (px)
DESCRIPTION
Citation preview
SPDYSPDY
Daniel Stenberg
Email: [email protected]: @bagderWeb: daniel.haxx.seBlog: daniel.haxx.se/blog
● Free Software● Network hacker● Embedded developer● Consultant
network and protocols● created curl● lead cares and libssh2● participate within IETF's HTTPbis,
ftpext2, httpstate, hybi and more
Agenda● Why SPDY
● Goals
● Who makes SPDY
● Basic features
● Some Numbers
● Critiques
● Implementations
● Alternatives
● can TCP improve?
● SPDY for curl
● Future
Questions?● interrupt!● comment!● remark!
Why SPDY● Growing HTTP requests –
uncompressed headers
● HTTP pipelining problems
● Desire for multiple simultaneous transfers
● TCP 3way handshake
● TCP slow start
● Clientonly initiated requests
● HTTP has Optional compression
● Mozilla bug 264354 open since Oct 2004
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
Who makes SPDY● Created by Google in 2009● Pioneered in Chrome● Discussed in the open● Several independent
implementations
Basic features● Multiplexed streams● Request prioritization● HTTP header compression● Serverinitiated streams
Multiplexed streams
Single TCP
Multiple streams● Cheap to create new● Amount limit can be set by peer
but it is unlimited by default● Perstream flowcontrol (hello
SCTP!)
Request prioritization● Each stream has a 07 priority● sender and recipient SHOULD use
besteffort to process streams in prio order
HTTP header compression● zlib compression● prepopulated compression
dictionary● request headers: ~88% reduction● response headers: ~85%
reduction
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
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
Some implementations● Chrome● Firefox● Amazon Kindle Fire● more!
Alternative paths● Waka 2002● HTTPMPLEX 2008● HTTP pipelining with several TCP
connections● SCTP● SSH?● MPTCP
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!
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
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
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?
Summary● SPDY speeds up the web● There's no viable alternatives● It will not replace HTTP within a
foreseeable future
Stuff to read
http://www.blaze.io/mobile/http-pipelining-big-in-mobile/http://www.blaze.io/technical/http-pipelining-request-distribution-algorithms/http://www.mnot.net/blog/2011/08/05/pipeline_nowhttp://tools.ietf.org/html/draft-cheng-tcpm-fastopen-00http://code.google.com/speed/articles/tcp_initcwnd_paper.pdfhttp://conferences.sigcomm.org/imc/2011/docs/p569.pdfhttp://www.chromium.org/spdyhttp://www.libspdy.org/http://daniel.haxx.se/blog/2011/10/18/libspdy/
SPDYSPDY
Daniel Stenberg
Email: [email protected]: @bagderWeb: daniel.haxx.seBlog: daniel.haxx.se/blog
● Free Software● Network hacker● Embedded developer● Consultant
network and protocols● created curl● lead cares and libssh2● participate within IETF's HTTPbis,
ftpext2, httpstate, hybi and more
Agenda● Why SPDY
● Goals
● Who makes SPDY
● Basic features
● Some Numbers
● Critiques
● Implementations
● Alternatives
● can TCP improve?
● SPDY for curl
● Future
Questions?● interrupt!● comment!● remark!
Why SPDY● Growing HTTP requests –
uncompressed headers
● HTTP pipelining problems
● Desire for multiple simultaneous transfers
● TCP 3way handshake
● TCP slow start
● Clientonly initiated requests
● HTTP has Optional compression
● Mozilla bug 264354 open since Oct 2004
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
Who makes SPDY● Created by Google in 2009● Pioneered in Chrome● Discussed in the open● Several independent
implementations
Basic features● Multiplexed streams● Request prioritization● HTTP header compression● Serverinitiated streams
Multiplexed streams
Single TCP
Multiple streams● Cheap to create new● Amount limit can be set by peer
but it is unlimited by default● Perstream flowcontrol (hello
SCTP!)
Request prioritization● Each stream has a 07 priority● sender and recipient SHOULD use
besteffort to process streams in prio order
HTTP header compression● zlib compression● prepopulated compression
dictionary● request headers: ~88% reduction● response headers: ~85%
reduction
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
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
Some implementations● Chrome● Firefox● Amazon Kindle Fire● more!
Alternative paths● Waka 2002● HTTPMPLEX 2008● HTTP pipelining with several TCP
connections● SCTP● SSH?● MPTCP
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!
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
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
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?
Summary● SPDY speeds up the web● There's no viable alternatives● It will not replace HTTP within a
foreseeable future
Stuff to read
http://www.blaze.io/mobile/http-pipelining-big-in-mobile/http://www.blaze.io/technical/http-pipelining-request-distribution-algorithms/http://www.mnot.net/blog/2011/08/05/pipeline_nowhttp://tools.ietf.org/html/draft-cheng-tcpm-fastopen-00http://code.google.com/speed/articles/tcp_initcwnd_paper.pdfhttp://conferences.sigcomm.org/imc/2011/docs/p569.pdfhttp://www.chromium.org/spdyhttp://www.libspdy.org/http://daniel.haxx.se/blog/2011/10/18/libspdy/
