University of Delaware - Improving Web Protocols (early SPDY talk)
1 like922 views
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.
![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](https://image.slidesharecdn.com/univofdelawarespdypresentation-130217231520-phpapp02/85/University-of-Delaware-Improving-Web-Protocols-early-SPDY-talk-17-320.jpg)
![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](https://image.slidesharecdn.com/univofdelawarespdypresentation-130217231520-phpapp02/85/University-of-Delaware-Improving-Web-Protocols-early-SPDY-talk-32-320.jpg)
More Related Content
What's hot (20)
Similar to University of Delaware - Improving Web Protocols (early SPDY talk) (20)
University of Delaware - Improving Web Protocols (early SPDY talk)
- 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
- 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
- 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.