University of Delaware - Improving Web Protocols (early SPDY talk)

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.