I gave this presentation to the W3C TAG in Nov, 2011. The meeting notes are published here: http://www.w3.org/2001/tag/2011/11/04-minutes

1. SPDY
Moving to Standardization

2. Why am I talking to the W3C?

3. Major Players Already Engaged
● Google: Uses SPDY for all SSL Traffic
○ see about:net-internals in Chrome
● Firefox
○ currently implementing SPDY
● Amazon Kindle Fire
○ launching in a couple of weeks
○ using a very different, but wicked cool model for SPDY

4. Why did Google build SPDY?

5. What is SPDY?
● Multiplexing
○ Get the data off the client
● Compression
○ HTTP headers are excessive
○ Uplink bandwidth is limited
● Prioritization
○ Today the browser holds back
○ Priorities enable multiplexing
● Server Push
○ Websites do some of this today with data URLs

6. Why SSL?
● Technically a myth, SPDY doesn't require SSL.
● Started as a deployment reality
● But we need to secure the net.
○ Not just for finance and banks anymore!

7. What about Proxies?
● Proxies cause a lot of problems.
○ example: Pipelining, WebSockets
● We need to transition to explicit proxies instead of implicit
○ This is a hard change.
● SPDY does not address cacheable, secured content. It's
simply out-of-scope for the project, but a very worthy project
to solve.

8. What does Firefox say?
From Patrick McManus:
Number of parallel connections is exploding:
● NYT home page: 83 connections
● Google+: 64 connections
● Facebook photos: 75 connections
He points out:
● This creates horrible NAT pressure.
● 83 concurrent tcp control blocks has potential for enormous
queues
● "That means HTTP breaks real time apps - SPDY lets us
mitigate that problem"

9. What is Kindle Fire doing?
Amazon
Kindle Internet
Service
A single SPDY connection
for everything.

10. Time to Standardize
● It's clear others are finding SPDY compelling
○ Google, Firefox, Amazon, Cotendo, Strangeloop
● We don't want a non-interoperable pile of goo.
● Google is happy to standardize, and individuals from Google
would like to play a role. But it will take its own form.
● Planning to do this through IETF in 2012.

11. Extra slides

12. With multiplexing:

13. HTTP Connections
Average: 29 connections per page.
25%-tile = 10 50%-tile = 20 75%-tile = 39 95%-tile = 78

14. Deployment: Process of Elimination
● Avoid changing the lower-level transport
● Available transports: TCP or UDP.
○ Note: SCTP not an option due to NAT.
● UDP
○ We'd have to re-engineer TCP features.
● That leaves us with TCP.
○ Ok, so which port? 80 or 443?

15. Deployment: Port 80
● Should be our first choice.
● Except HTTP runs on port 80.
● Proxies and intermediates make for
a treacherous environment.
○ HTTP/1.1 1999 - Pipelining still not deployed
○ Compression negotiation
● Upgrade header requires a round trip
● WebSockets Data Shows that using HTTP over a non-
standard port is less tampered with than port 80.
○ Success rate:
■ HTTP (port 80) 67%
■ HTTP (port 61985) 86%
■ HTTPS (port 443) 95%

16. Deployment: Port 443
● Port 443 runs SSL/TLS.
○ Adds server authentication & encryption
● Handshake is extensible:
○ Next-Protocol-Negotiation
www.ietf.org/id/draft-agl-tls-nextprotoneg-00.txt

17. Less is More - Conns, Bytes, Packets

18. Request Path
SPDY (closer to actual)
SPDY (human readable)
80 01 00 01
SYN frame
00 00 00 6b
stream_id = 1
00 00 00 01
associated_stream_id = 0
00 00 00 00
priority = 1
40 00 00 04
num_headers = 4
06method04post
[6]method[4]POST
03url1ahttp://blogger.com/my_blog
[3]url[26]http://blogger.com/my_blog
0auser-agent13blahblahblah chrome
[10]user-agent[19]blahblahblah chrome
07version08http/1.1
[7]version[8]HTTP/1.1
DATA frame
stream_id = 1
00 00 00 01
flags = fin
01 00 00 1f
length = 31
here is my very short blog post
here is my very short blog post

19. Why does SPDY require SSL?
● It doesn't.
● Started as a deployment challenge.
● However, Chrome will never ship a version that is not SSL
based, Firefox engineers agree as well.