Upload
mike-belshe
View
108
Download
1
Tags:
Embed Size (px)
DESCRIPTION
I visited at the University of Delaware and presented these slides on April 08, 2011.
Citation preview
Improving Web ProtocolsSPDY Performance Data
mbelshe - 04-08-11
Motivation
Latency & Security
Can't We Address Latency & Security Separately?
No.
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...
Requirements
● 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
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!
Background: What is a WebPage?
● ~44 resources● ~7 hosts● ~320KB● ~66% compressed (top sites are ~90% compressed)● Except HTTPS, where < 50% compressed.
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
Background: HTTP Connections
Average: 29 connections per page.
25%-tile = 10 50%-tile = 20 75%-tile = 39 95%-tile = 78
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 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
● 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?
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
With multiplexing:
Request Path
SPDY (closer to actual)80 01 00 0100 00 00 6b 00 00 00 0100 00 00 0040 00 00 04 06method04post03url1ahttp://blogger.com/my_blog0auser-agent13blahblahblah chrome07version08http/1.1
00 00 00 0101 00 00 1fhere is my very short blog post
SPDY (human readable) SYN framestream_id = 1associated_stream_id = 0priority = 1num_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.1DATA framestream_id = 1flags = finlength = 31here is my very short blog post
Does it work?
"Figures don't lie, but liars can figure"
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.
Initial Results: Packet Loss
Real world packet loss is ~1%.
SPDY is 41%-47% faster for PL between 1 and 2%.
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 Results: Page Load Time
Less is More - Conns, Bytes, Packets
Increasing Parallelism
HTTPS vs SPDY (Production)
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
TLS - False Start
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
TLS - Snap Start
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)● going to change (and you can help guide it!)
HTTP vs HTTPS vs SPDY (lab)
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
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 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
Next Steps
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.