ºÝºÝߣ

ºÝºÝߣShare a Scribd company logo

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

?
?
Mike Belshe
Mike Belshe

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 of 37
Download to read offline
Improving Web Protocols SPDY 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 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
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
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) 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
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)
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.

More Related Content

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