SPDY is a protocol developed by Google to improve web performance by addressing latency and security issues on the web. It allows for multiplexing of requests over a single TCP connection to reduce round trips and connection overhead. Initial testing showed SPDY reduced page load times by 40% on average compared to HTTP. Google has deployed SPDY internally and it is enabled by default in Chrome, but more work is still needed for full standardization and deployment.

1. Improving Web Protocols
SPDY Performance Data
mbelshe - 04-08-11

2. Motivation
Latency & Security

3. Can't We Address Latency & Security
Separately?
No.

4. Can't We Address Latency & Security
Separately?
● If eavesdropping in the cafe is still possible in 2020 with
trivial tools, we have failed our users.
● The internet is weak already and getting worse.
● Firesheep tools make sniffing easy
● Major content providers want privacy
○ Facebook opt-in
○ Twitter opt-in
○ Google wants it too.
○ SSL is just too slow right now...

5. Requirements
● Avoid requiring the website author to change content
Allow for incremental changes
Performing "better" with content changes is okay
Performing "worse" without content changes is unacceptable
● Perform always better, never worse than HTTP
● Drop-in replacement from webapp's point of view
○ Changing the web server/application server is inevitable
and therefore acceptable

6. Incremental Improvements - Meh.
● Incremental improvements to HTTP don't "move the needle"
○ They're hard to figure out individually
○ Each only works for some people, with hacks
● Problem is the intermediaries (a.k.a. proxies)
○ Transparent proxies change the content.
○ Example: pipelining - donde esta?
○ Example: stripped "Accept-Encoding" headers
■ we can't even improve "negotiated" compression!
● Intermediaries make the web a hostile place for protocol
changes.
● Even our laws get in the way.
○ Spying on us is bad, but spying on our kids is ok!

7. Background: What is a WebPage?
● ~44 resources
● ~7 hosts
● ~320KB
● ~66% compressed (top sites are ~90% compressed)
● Except HTTPS, where < 50% compressed.

8. Background: Poor Network Utilization
Web Page evolution has led to poor network utilization.
Bandwidth is going up... RTT isn't going down.

9. Background: Pesky Round Trips

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

11. Transport or Application Layer?
● Known transport problems
○ lots of small connections with no shared state
○ no data in handshake
○ slow-start
○ delayed ack
● Known app layer problems
○ Single threaded connections
○ Redundant headers
○ Not enough compression
● Decision:
○ App layer problems were too severe to ignore
○ Packet loss patterns unknown

12. How to Deploy? Process of Elimination
● Avoid changing the lower-level transport
○ Much easier "burden of proof"
○ Works with existing infrastructure
● Available transports:
○ TCP, UDP are possible.
○ SCTP not an option due to NAT.
● UDP
○ We'd have to re-engineer TCP features.
● That leaves us with TCP.
○ Only two ports available universally
■ Port 80?
■ Port 443?

13. 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%

14. 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
● But isn't TLS too slow?
○ CPU issues are minor
○ TLS does increase bandwidth by 2-3%
■ Mitigated by SPDY better compression.
○ Round Trip Times are significant
○ SSL requires 2 or 1 RTs for the handshake
■ Can we reduce to 0 RTs?

15. What is SPDY?
● Goal: Reduce Web Page Load time.
● 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
● Encrypted & Authenticated
○ Eavesdropping at the Cafe must be stopped
● Server Push
○ Websites do some of this today with data URLs

16. With multiplexing:

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

18. Does it work?
"Figures don't lie, but liars can figure"

19. Initial Results - Testing Methods
● 3 major variables on the network
○ Packet Loss
○ Bandwidth
○ Round-Trip-Time
● Looking at any one configuration is anecdotal, need to look
at a spectrum of data.
● Our test content includes:
○ high-fidelity copies of top-25 web pages.
○ includes exact HTTP headers, compression, etc.
● Packet loss simulators stink (random loss is not realistic)
○ We don't have a good model.
○ We don't have a good simulator.

20. Initial Results: Packet Loss
Real world packet
loss is ~1%.
SPDY is 41%-47%
faster for PL between
1 and 2%.

21. Top 300 Content
Question: Do highly
optimized websites get
less benefit?
Randomly picked 300
sites from the Alexa
Top-1000.
Overall page load
improvement average
was 40%.

22. Initial Results: Page Load Time

23. Less is More - Conns, Bytes, Packets

24. Increasing Parallelism

25. HTTPS vs SPDY (Production)

26. TLS - Can we tune it now?
● TLS is an unoptimized frontier for browsers
● Browser features:
○ Certificate caching
○ Validation caching
○ Parallel validation/connecting
○ OCSP stapling
■ multi-level OCSP stapling
○ False Start
○ Snap Start
● more more more

27. TLS - False Start

28. TLS - Snap Start
● 0-RTT SSL
● We built it.
○ Don't like it.
● Doesn't do perfect forward secrecy
● Changes too complex when retrofitted atop existing SSL
● http://tools.ietf.org/html/draft-agl-tls-snapstart-00

29. TLS - Snap Start

30. Deployment Status @ Google
● On by default since Chrome 6
○ Currently at 90%; 10% holdback is for A/B testing.
● On for all Google SSL traffic
● SPDY HTTP->SPDY proxy used externally some
● SPDY Proxy
● Android just getting started, Honeycomb/Clank.
In other words, yes, you can really use it now.
But SPDY is:
● experimental
● research
● not standardized (yet)

31. HTTP vs HTTPS vs SPDY (lab)

32. Poor Man's WebSocket Today
● docs.google.com has a "hanging GET" for every doc open
● how to scale beyond 6 connections per domain?
○ docs[1-N].google.com
● but, gets expensive and is horribly inefficient
● switched to spdy and much happier
● Header compression mitigates some of the inefficiency of a
hanging GET

33. New Bottlenecks

34. How Much Does A Handshake Cost?

35. Single Connection Throttles
● Initial cwnd is still a problem
○ mitigated with kernel changes, but who can deploy that?
● Initial receive window too low on Linux
○ fixed on trunk, but need to update all client kernels!
● TCP intermediaries
○ See bugs all the time that muck with wscale and other
options causing slow single connections
● TCP congestion control
○ Completely unfair backoff for single-connection protocols
○ Single connection: single loss loses 1/2 of bandwidth
○ HTTP (6 conn): single loss loses 1/12 of bandwidth

36. Next Steps

37. Next Steps
● Chrome Changes
○ Added SPDY IP Pooling
○ Need to persist dynamic cwnd data
○ Server Push
○ More measurements
● SSL Changes
○ Scratching Snapstart
○ Need a new protocol
● Transport Changes
○ Need a protocol we can actually deploy.
○ TCP in the kernel isn't it.