SPDY Essentials

Will Chan

Roberto Peon

Topics

• Why SPDY?
• What is SPDY?
• SPDY Performance Benefits
• SPDY Deployment Status
• Future Work

State of the Web Page (May 2010)

• An average Web Page Consists of:
• ~44 resources
• ~7 hosts
• ~320KB
• ~66% compressed (top sites are ~90% compressed)
• Note: HTTPS is < 50% compressed.
• Incremental improvements to HTTP don't move the needle
• Transparent proxies change the content.
• Example:  pipelining
• Example:  stripped "Accept-Encoding" headers
• we can't even improve "negotiated" compression!

HTTP Connection Use 2010

• Average: 29 connections per page.

​

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

Goals

• Avoid requiring the website author to change contentAllow for incremental changesPerforming "better" with content changes is okayPerforming "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

​

Quick SPDY Background

• Goals:
• Faster web page downloads
• Always secure
• Deployable
• Open
• Features (No rocket science here!)
• Single-connection, Multiplexed, Prioritized streams
• Mandatory header compression
• Supports server-push
• SPDY is Basic Networking "blocking and tackling"
• Use fewer connections
• Send fewer bytes

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

Reducing Upload Bytes

​

Reducing Download Bytes

​

Reducing Total Packets

Increasing Parallelism

Comparison to Pipelining

• Pro Pipelining
• Works for some portion of the internet today
• No SSL requirement

​

• Pro SPDY
• No deployment 'heuristics', it just works
• Full multiplexing
• Better compression
• Server Push
• No head-of-line blocking

​

Background: Poor Network Utilization

• Web Page evolution has led to poor network utilization.
• Bandwidth is going up...  RTT isn't going down.

​

​

​

Background: Pesky Round Trips

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
• Barrier on transport too high without addressing App first

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?

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 (measured late 2009) shows surprising results for success rate of client+server speaking agreed-upon non-HTTP protocol. HTTPS is best, new port second best. Port 80... not so good
• Success rate:
• HTTP  (port 80)    67%
• HTTP  (port 61985) 86%
• HTTPS (port 443)   95%

Deployment: Port 443

• Port 443 runs SSL/TLS.
• Adds authentication & encryption
• Handshake is extensible:
• Next-Protocol-Negotiationwww.ietf.org/id/draft-agl-tls-nextprotoneg-00.txt
• But isn't TLS too slow?
• CPU issues are minor for decent implementations
• 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?

With multiplexing:

Request Path

•                  SPDY (in reality, headers are compressed)
•  
• 80 01 00 01
• 00 00 00 6b  
• 00 00 00 01
• 00 00 00 00
• 40 00 00 04  
• 06method04post
• 03url1ahttp://blogger.com/my_blog
• 0auser-agent13blahblahblah chrome
• 07version08http/1.1 

​

​

• 00 00 00 01
• 01 00 00 1f
• here is my very short blog post

•                       SPDY (human readable)
•  
• SYN frame
• stream_id = 1
• associated_stream_id = 0
• priority = 1
• num_headers = 4
• [6]method[4]POST
• [3]url[26]http://blogger.com/my_blog
• [10]user-agent[19]blahblahblah chrome
• [7]version[8]HTTP/1.1
•  
• DATA frame
• stream_id = 1
• flags = fin
• length = 31
• here is my very short blog post

​

​

​

​

​

​

​

Does it work?

• "Figures don't lie, but liars can figure"

​

Initial Lab 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.

Initial Lab Results: Packet Loss

• Real world packet loss is ~1%.

​

• SPDY-no-SSL is 41%-47% faster for PL between 1 and 2%.

Initial Lab Results: 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%.

Initial Lab Results: Page Load Time

Less is More - Conns, Bytes, Packets

HTTPS vs SPDY Overall (Production)

SPDY vs HTTP for Google Websearch

• SSL search became the default in Nov for google.com logged in users.
• AJAX search is faster over SPDY than HTTP.
• ​
• Obviously, Google cares about the quality of its websearch experience, so this was a 'wow' moment.
• ​
• Hopefully more details and measurements to be presented at the upcoming Velocity conference.
• ​
• ​

Deployment Status

• SPDY is on by default since Chrome 6
• Currently at 95%; 5% holdback is for A/B testing.
• On for all Google SSL traffic
• SPDY HTTP<->SPDY proxy from chromium used externally by others
• SPDY Proxy (Kindle Fire's Silk Browser)
• Android browser supports it since Honeycomb.
• Firefox will support it (off by default, but user selectable) in FF11.
• mod_spdy (work in progress)
• Many other language implementations (C/Ruby/Python/Go/Erlang/node.js/etc)
• ​
• In other words, yes, you can really use it now.
• ​
• But SPDY is:
• not standardized (yet)
• still evolving (and you can help guide it!)

New Bottlenecks

How Much Does A Handshake Cost?

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 stacks!
• 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

Next Steps

Help the community

• We'll be working on providing:
• updated draft-3 spec
• spdy compliance test suite
• split out SPDY<->HTTP gateway proxy away from chromium codebase so it is more easily compiled
• mod_spdy in Apache
• implementation best practices
• ​

Document SPDY 'best practices'

• use a single connection
• set initcwnd to 10
• watch your cert size
• watch for cert chaining
• use wildcard certs, if possible
• turn off tcp_slow_start_after_idle
• use reasonably small SSL write buffer sizes
• don't shard domains
• use server push instead of inlining
• ensure reasonable priorities: html > js,css > *
• pick a reasonably small framesize
• leverage persistent settings

Server Push vs Inlining

• Server Push is quite a bit better than inlining since:
• The content is still client-cachable when you use Server Push
• Server Push never expands the size of the resource, unlike inlining
• ​
• We should get web pages to use server push!

Research TCP-level improvements

• SPDY provides an improvement overall today, but for high-latency high-loss links, the use of a single connection can be detrimental.
• ​
• We're researching ways around this today.

Standardization

• We're planning on starting the standardization process at the Spring instance of IETF for SPDY.
• ​
• We're separately pursuing standardization for the Next Protocol Negotiation (NPN) extension to TLS, upon which SPDY currently depends, but which is also not SPDY specific.

Areas for Research

Allow the server to authenticate for other hostnames

• SPDY allows connection-pooling, but currently only allows this to occur when the cert which was served matches the domain.
• ​
• Instead we could allow the server to serve another cert, which the browser verifies, thus allowing the connection to be shared for more domains and reducing latency.

Allow the server to republish DNS information

• With the advent of secure DNS, it may be possible to reshare DNS information securely.
• ​
• In such cases, it may be interesting to allow the server to re-publish DNS information, removing that latency and allowing the server to steer load.

Tunnel WebSocket and other protocols

• Since SPDY is stream oriented, it should be easy to tunnel or map WebSocket or other protocols onto SPDY, allowing for connection sharing.