SPDY

Daniel Stenberg● Free Software● Network hacker● Embedded developer● Consultant Email: daniel@haxx.se Twitter: @bagder Web: daniel.haxx.se Blog: daniel.haxx.se/blog

network and protocols● created curl● lead cares and libssh2● participate within IETFs HTTPbis, ftpext2, httpstate, hybi and more

Agenda● Why SPDY ● Alternatives● Goals ● can TCP improve?● Who makes SPDY ● SPDY for curl● Basic features ● Future● Some Numbers● Critiques● Implementations

Questions?● interrupt!● comment!● remark!

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

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● curls 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● Theres no viable alternatives● It will not replace HTTP within a foreseeable future

Stuff to readhttp://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/