• Save
From Fast to SPDY - Velocity 2011
Upcoming SlideShare
Loading in...5
×
 

From Fast to SPDY - Velocity 2011

on

  • 554 views

original share at: http://www.slideshare.net/ido-cotendo/from-fast-to-spdy-velocity-2011 ...

original share at: http://www.slideshare.net/ido-cotendo/from-fast-to-spdy-velocity-2011

Improving Performance by Changing the Rules - From Fast to SPDY

Ido Safruti (Cotendo Inc), Mike Belshe (Google)
1:50pm Wednesday, 06/15/2011

http://velocityconf.com/velocity2011/public/schedule/detail/21089

Statistics

Views

Total Views
554
Views on SlideShare
554
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
2

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

12 of 2

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • this presentation was given over 2 years ago. there is more data on SPDY and stats that came in the last 2 years, after having FB, Twitter and other vendors implement/support SPDY. most (or all) implementations of SPDY so far replaced SSL, or came together with the growing efforts to move more and more traffic to be SSL by default.
    I am not sure i am following your question on no caching over SSL. this is relevant only for transparent proxies, which are blind to SSL/TLS to begin with. devices can definitely cache content delivered over TLS/SSL.
    as for 3G - actually SPDY is much friendlier to the network, given it utilizes a single connection, but that reducing netowkr overhead, buffer-bloating effects and so on.
    Are you sure you want to
    Your message goes here
    Processing…
  • what about data, does SPDY requires more data duo to no caching over SSL? does it affects the costs of using 3G ?
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    From Fast to SPDY - Velocity 2011 From Fast to SPDY - Velocity 2011 Presentation Transcript

    • From Fast to SPDY Ido Safruti, Mike Belshe,
    • SPDY
    • SPDYee
    • Agenda  Challenges of HTTP/1.1  SPDY  Some data, and results  How we tune today  What’s next
    • rfc2616: HTTP/1.1 drafted:1998 released June 1999
    • What else was there in 1998
    • What else was there in 1998
    • What else was there in 1998
    • What else was there in 1998
    • What else was there in 1998
    • What else was there in 1998
    • What else was there in 1998 http://web.archive.org/web/19980425182703/http://geocities.com/
    • What else was there in 1998 4/25/1998 no external scripts or css files 20 images, ~65KB entire page http://web.archive.org/web/19980425182703/http://geocities.com/
    • Did They Plan for That!?
    • HTTP/1.1  Compression  Headers  Poor connection management  Only one request can be done at a time (Half duplex)  Particularly important on high latency links (mobile)  short lived connections  security - optional
    • Compression * http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
    • Compression Optional Only for response body ~99% of browsers support * http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
    • Compression Optional Only for response body ~99% of browsers support Particularly important on small pipes (mobile) * http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
    • Compression Optional Only for response body ~99% of browsers support Particularly important on small pipes (mobile) 15%-30% of responses not compressed for no good reason!* for SSL even worse * http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
    • Compression Optional Only for response body ~99% of browsers support Particularly important on small pipes (mobile) 15%-30% of responses not compressed for no good reason!* for SSL even worse no request compression * http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
    • Compression Optional Only for response body ~99% of browsers support Particularly important on small pipes (mobile) 15%-30% of responses not compressed for no good reason!* for SSL even worse no request compression no header compression * http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
    • Headers  Redundant  Repeat on EVERY request/response  Can’t compress  User-agent  Cookies
    • HTTP Connection - under the hood Client Server
    • HTTP Connection - under the hood TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Client Server
    • HTTP Connection - under the hood TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Client Server
    • HTTP Connection - under the hood Request/Response = 0.5 RTT TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Client Server
    • HTTP Connection - under the hood Request/Response = 0.5 RTT TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Client Server }
    • HTTP Connection - under the hood Request/Response = 0.5 RTT TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Client Server } }
    • HTTP Connection - under the hood Request/Response = 0.5 RTT TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Client Server } } Spun additional connections
    • HTTP Connection - under the hood Request/Response = 0.5 RTT TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Slow Start - 30KB ~ 4 RTT (vs. 1 RTT warm) Client Server Spun additional connections
    • Global US Mobile - US Mobile - EU BW Mbps 1.9 5.1 1.1 ~2 User Data: average bandwidth Source: State of the Internet, Q4 2010 http://www.akamai.com/stateoftheinternet/ User Data: average RTT Broadband Coast-to-Coast 3G device-GW RTT ms 30 100 80-200 “Lost” Capacity on each RTT US Broadband: 63.7KB US Mobile: 27.5KB Average obj size 8.1KB Source: HTTP Archive, 6/1/2011 data for Top 1,000 http://httparchive.org
    • http://desktopsecuritysoftwareguide.com/wp-content/uploads/2010/04/Padlock.jpg Security is optional
    • Enters SPDY!
    • 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
    • What is SPDY?  Goal: Reduce Web Page Load time.  Multiplexing  Better utilize client connections  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
    • Deployment Status
    • Deployment Status  Google  Enabled for all Google SSL traffic  On by default since Chrome 6
    • Deployment Status  Google  Enabled for all Google SSL traffic  On by default since Chrome 6  CDNs/Service providers:  Cotendo
    • Deployment Status  Google  Enabled for all Google SSL traffic  On by default since Chrome 6  CDNs/Service providers:  Cotendo  Server implementations:  Strangeloop  SPDY Proxy available  Others: C++, Python, Ruby, Go
    • Deployment Status  Google  Enabled for all Google SSL traffic  On by default since Chrome 6  CDNs/Service providers:  Cotendo  Server implementations:  Strangeloop  SPDY Proxy available  Others: C++, Python, Ruby, Go  Client implementation  Chrome  Android coming...
    • Results
    • Yahoo! Homepage, over broadband network
    • Yahoo! homepage HTTP Broadband RTT = 20ms Page Load: 1.23sec
    • Yahoo! homepage SPDY (via Cotendo) Broadband RTT = 20ms Page Load: 1.21sec -2%
    • Amazon.com Homepage, over 3G network
    • Page Load: 12.50sec Amazon.com Homepage HTTP 3G,AT&T RTT = 200+ms
    • Amazon.com Homepage SPDY (via Cotendo) 3G AT&T RTT = 200+ms Page Load: 6.26sec -49%
    • HTTPS vs SPDY (Production)
    • Increasing Parallelism
    • Less is More - Conns, Bytes, Packets
    • Not Too Shabby WebSockets  docs.google.com has a "hanging get" for every doc open  how to scale beyond 6 connections per domain?  docs[1-N].google.com  gets expensive, complicated, and is horribly inefficient  SPDY is easy, works great, efficient  Header compression mitigates the inefficiency of a hanging GET
    • Can't We Address Latency & Security Separately?
    • 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.  Security is not just for banks!  Social/Mail/Content is a major target  example: Comodo attack  Firesheep tools make sniffing easy  Major content providers want privacy  Facebook opt-in  Twitter opt-in  Google working toward 100%
    • How we tune today
    • High Performance Web Sites 1.Make fewer HTTP requests 2.Use CDN 3.Add expires header 4.Gzip Components 5.Put stylesheets at the top 6.Put scripts at the bottom 7.Avoid CSS expressions 8.Make JS and CSS external 9.Reduce DNS lookups 10.Minify JS 11.Avoid redirects 12.Remove duplicate scripts 13.Configure Etags 14.Make Ajax cacheable 15.Sharding domains
    • High Performance Web Sites 1.Make fewer HTTP requests 2.Use CDN 3.Add expires header 4.Gzip Components 5.Put stylesheets at the top 6.Put scripts at the bottom 7.Avoid CSS expressions 8.Make JS and CSS external 9.Reduce DNS lookups 10.Minify JS 11.Avoid redirects 12.Remove duplicate scripts 13.Configure Etags 14.Make Ajax cacheable 15.Sharding domains Due To HTTP Lim itations!
    • Firetruck
    • Domain Sharding
    • Domain Sharding  Pros:  Parallelism in HTTP  Cookieless domains for static content
    • Domain Sharding  Pros:  Parallelism in HTTP  Cookieless domains for static content
    • Domain Sharding  Pros:  Parallelism in HTTP  Cookieless domains for static content  Cons:  DNS time  Connection establishment overhead  TCP slowstart / warmup  SSL  maintaining many connections  user cache  Prevents browser optimizations
    • Reduce number of requests  Inlining  Spriting  Data URLs  Combining javascripts and CSS files  Cons:  reduced cache efficiency  Complicated
    • New Class of FEO
    • Rethink your optimizations  As rules change, your need to re-evaluate your best practices  13 years is a long time! start at the beginning...  But also presents many new opportunities  Delivery priorities  Smart Push  Simple web code  Automate!
    • Image Compression HTML 6.5 Scripts 13.0 Stylesheets 3.5 Images 55.0 Other 7.0 HTML 32 Scripts 119 Stylesheets 25 Images 415 Other 99 Number of Requests Transfer Size in KB Source: http://httparchive.org/trends.php?s=Top1000
    • In mobile even stronger! HTML 42 Scripts 80 Stilesheets 20 Images 228 Other 6 HTML 4 Scripts 7 Stilesheets 2 Images 31 Other 2 Number of Requests Transfer Size in KB Source: http://mobile.httparchive.org/trends.php?s=Top1000
    • Lossy compression is the way to go! Billy Hoffman / Zoompf AP Photo/John Bazemore
    • http://www.flickr.com/photos/tracy_olson/61056391/ Lossy-Compression is Not for Everything
    • Progressive image compression http://images.sixrevisions.com/2010/12/01-02_baseline_vs_progressive.jpg
    • Client Server
    • Client Server Get HTML
    • Client Server
    • Client Server Get all objects
    • 20% Client Server 20%20% 20%20%
    • Client Server 80% 80%80% 80%80%
    • Summary
    •  SPDY actually delivers!
    •  SPDY actually delivers!  but we are still in the early phases
    •  SPDY actually delivers!  but we are still in the early phases  participate and be part of the solution
    •  SPDY actually delivers!  but we are still in the early phases  participate and be part of the solution
    •  SPDY actually delivers!  but we are still in the early phases  participate and be part of the solution  Rules CAN be broken. Changes are possible!
    •  SPDY actually delivers!  but we are still in the early phases  participate and be part of the solution  Rules CAN be broken. Changes are possible!  HTTP is built into the internet architecture, it can’t be changed.
    •  SPDY actually delivers!  but we are still in the early phases  participate and be part of the solution  Rules CAN be broken. Changes are possible!  HTTP is built into the internet architecture, it can’t be changed.  What’s next?
    •  SPDY actually delivers!  but we are still in the early phases  participate and be part of the solution  Rules CAN be broken. Changes are possible!  HTTP is built into the internet architecture, it can’t be changed.  What’s next?
    •  SPDY actually delivers!  but we are still in the early phases  participate and be part of the solution  Rules CAN be broken. Changes are possible!  HTTP is built into the internet architecture, it can’t be changed.  What’s next?  Opens the door to implement new class of optimizations
    •  SPDY actually delivers!  but we are still in the early phases  participate and be part of the solution  Rules CAN be broken. Changes are possible!  HTTP is built into the internet architecture, it can’t be changed.  What’s next?  Opens the door to implement new class of optimizations
    •  SPDY actually delivers!  but we are still in the early phases  participate and be part of the solution  Rules CAN be broken. Changes are possible!  HTTP is built into the internet architecture, it can’t be changed.  What’s next?  Opens the door to implement new class of optimizations  Get engaged NOW!
    • Measurement - Proving us Right  No 3rd party tools (yet)!  Chrome developer tools  not good for large scale data...  w3c Web Performance tools - Navigation Timing  Supported on IE9, and Chrome 11+  http://w3c-test.org/webperf/specs/NavigationTiming/  Site metrics:  Google Analytics
    • Ido Safruti, ido@cotendo.com Mike Belshe, mbelshe@google.com