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
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
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
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
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
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
