SPDY / W3C

SPDY

Moving to Standardization

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

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

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!

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.

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"

What is Kindle Fire doing?

Amazon
Kindle Internet
Service

A single SPDY connection
for everything.

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.

HTTP Connections

Average: 29 connections per page.

25%-tile = 10 50%-tile = 20 75%-tile = 39 95%-tile = 78

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?

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%

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

Less is More - Conns, Bytes, Packets

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

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.

SPDY / W3C

More Related Content

Similar to SPDY / W3C (20)

SPDY / W3C