Your SlideShare is downloading. ×
0
From Fast to SPDY   Ido Safruti,   Mike Belshe,
SPDY
SPDY ee
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                                   ...
Did They Plan for That!?
HTTP/1.1 Compression Headers Poor connection management  Only one request can be done at a time (Half duplex)  Partic...
Compression * http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
CompressionOptionalOnly for response body ~99% of browsers support * http://code.google.com/speed/articles/web-metrics.htm...
CompressionOptionalOnly for response body ~99% of browsers support Particularly important on small pipes (mobile) * http:/...
CompressionOptionalOnly for response body ~99% of browsers support Particularly important on small pipes (mobile)15%-30% o...
CompressionOptionalOnly for response body ~99% of browsers support Particularly important on small pipes (mobile)15%-30% o...
CompressionOptionalOnly for response body ~99% of browsers support Particularly important on small pipes (mobile)15%-30% o...
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...
HTTP Connection - under the hood                            TCP Connect + Request = 1.5 RTT                            TCP...
HTTP Connection - under the hood                            TCP Connect + Request = 1.5 RTT                            TCP...
HTTP Connection - under the hood                            TCP Connect + Request = 1.5 RTT                            TCP...
HTTP Connection - under the hood                            TCP Connect + Request = 1.5 RTT                            TCP...
HTTP Connection - under the hood                            TCP Connect + Request = 1.5 RTT                            TCP...
HTTP Connection - under the hood                            TCP Connect + Request = 1.5 RTT                            TCP...
“Lost” Capacity on each RTTUser Data:                                               User Data:average bandwidth           ...
Security is optionalhttp://desktopsecuritysoftwareguide.com/wp-content/uploads/2010/04/Padlock.jpg
Enters SPDY!
Requirements Avoid requiring the website author to change content  Allow for incremental changes  Performing "better" wit...
What is SPDY? Goal: Reduce Web Page Load time. Multiplexing   Better utilize client connections Compression   HTTP he...
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:  ...
Deployment Status Google   Enabled for all Google SSL traffic   On by default since Chrome 6 CDNs/Service providers:  ...
Deployment Status Google   Enabled for all Google SSL traffic   On by default since Chrome 6 CDNs/Service providers:  ...
Results
Yahoo! Homepage, over broadband network
Yahoo! homepage HTTP Broadband RTT = 20msPage Load: 1.23sec
Yahoo! homepage SPDY (via Cotendo) Broadband RTT = 20msPage Load: 1.21sec       -2%
Amazon.com Homepage, over 3G network
Amazon.com Homepage HTTP 3G, AT&T RTT = 200+msPage Load: 12.50sec
Amazon.com Homepage SPDY (via Cotendo) 3G AT&T RTT = 200+msPage 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 d...
Cant We Address Latency & Security Separately?
Cant We Address Latency & Security Separately?                    No.
Cant We Address Latency & Security Separately?  If eavesdropping in the cafe is still possible in 2020 with trivial tools...
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 a...
High Performance Web Sites 1.Make fewer HTTP requests 2.Use CDN 3.Add expires header 4.Gzip Components                    ...
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 establ...
Reduce number of requests Inlining Spriting Data URLs Combining javascripts and CSS files Cons:   reduced cache effi...
New Class of FEO
Rethink your optimizations As rules change, your need to re-evaluate your best practices    13 years is a long time! sta...
Image Compression  Number of Requests                                       Transfer Size in KB                 Other     ...
In mobile even stronger!   Number of Requests                                Transfer Size in KB              Other HTML  ...
Lossy compression is the way to go!    Billy Hoffman / Zoompf                                      AP Photo/John Bazemore
Lossy-Compression is      Not for Everythinghttp://www.flickr.com/photos/tracy_olson/61056391/
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
Client                                 Server         20%   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 ...
 SPDY actually delivers!    but we are still in the early phases    participate and be part of the solution Rules CAN ...
 SPDY actually delivers!    but we are still in the early phases    participate and be part of the solution Rules CAN ...
 SPDY actually delivers!    but we are still in the early phases    participate and be part of the solution Rules CAN ...
 SPDY actually delivers!    but we are still in the early phases    participate and be part of the solution Rules CAN ...
 SPDY actually delivers!    but we are still in the early phases    participate and be part of the solution Rules CAN ...
 SPDY actually delivers!    but we are still in the early phases    participate and be part of the solution Rules CAN ...
Measurement - Proving us Right No 3rd party tools (yet)! Chrome developer tools    not good for large scale data... w3...
Ido Safruti, ido@cotendo.comMike Belshe, mbelshe@google.com
Improving performance by changing the rules   from fast to SPDY
Improving performance by changing the rules   from fast to SPDY
Improving performance by changing the rules   from fast to SPDY
Upcoming SlideShare
Loading in...5
×

Improving performance by changing the rules from fast to SPDY

951

Published on

SPDY was proposed by Google back in November 2009 to reduce the latency and load time of web pages. It was provided as part of the Chromium open-source project and is enabled in Chrome by default.

We at Cotendo took on the challenge, implemented the server side, and extended our proxies to support SPDY, providing SPDY to HTTP “translation”. Guess what? It really speeds things up. But like all new good things, there is still work to do. We will share insights from our implementation, optimization of SSL-based traffic and present performance data both from Google’s and our customers’ deployment.
What’s next?

We believe the introduction of SPDY as a new application layer presents a unique opportunity to rethink web design concepts and front-end-optimization (FEO) techniques. We will discuss some optimizations we developed and suggest some guidelines on how you can approach these new types of optimizations.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
951
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
30
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Improving performance by changing the rules from fast to SPDY"

  1. 1. From Fast to SPDY Ido Safruti, Mike Belshe,
  2. 2. SPDY
  3. 3. SPDY ee
  4. 4. Agenda Challenges of HTTP/1.1 SPDY Some data, and results How we tune today What’s next
  5. 5. rfc2616: HTTP/1.1 drafted:1998 released June 1999
  6. 6. What else was there in 1998
  7. 7. What else was there in 1998
  8. 8. What else was there in 1998
  9. 9. What else was there in 1998
  10. 10. What else was there in 1998
  11. 11. What else was there in 1998
  12. 12. What else was there in 1998 http://web.archive.org/web/19980425182703/http://geocities.com/
  13. 13. 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/
  14. 14. Did They Plan for That!?
  15. 15. 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
  16. 16. Compression * http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
  17. 17. CompressionOptionalOnly for response body ~99% of browsers support * http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
  18. 18. CompressionOptionalOnly for response body ~99% of browsers support Particularly important on small pipes (mobile) * http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
  19. 19. CompressionOptionalOnly 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
  20. 20. CompressionOptionalOnly 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 worseno request compression * http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
  21. 21. CompressionOptionalOnly 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 worseno request compressionno header compression * http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
  22. 22. Headers Redundant Repeat on EVERY request/response Can’t compress User-agent Cookies
  23. 23. HTTP Connection - under the hood Client Server
  24. 24. HTTP Connection - under the hood TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Client Server
  25. 25. HTTP Connection - under the hood TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Client Server
  26. 26. HTTP Connection - under the hood TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Request/Response = 0.5 RTT Client Server
  27. 27. HTTP Connection - under the hood TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Request/Response = 0.5 RTT } Client Server
  28. 28. HTTP Connection - under the hood TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Request/Response = 0.5 RTT } } Client Server
  29. 29. HTTP Connection - under the hood TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Request/Response = 0.5 RTT } Spun additional connections } Client Server
  30. 30. HTTP Connection - under the hood TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Request/Response = 0.5 RTT Slow Start - 30KB ~ 4 RTT (vs. 1 RTT warm) Spun additional connections Client Server
  31. 31. “Lost” Capacity on each RTTUser Data: User Data:average bandwidth average RTT BW Mbps RTT ms Global 1.9 Broadband 30 US 5.1 Coast-to-Coast 100 Mobile - US 1.1 3G device-GW 80-200 Mobile - EU ~2Source: State of the Internet, Q4 2010http://www.akamai.com/stateoftheinternet/ 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
  32. 32. Security is optionalhttp://desktopsecuritysoftwareguide.com/wp-content/uploads/2010/04/Padlock.jpg
  33. 33. Enters SPDY!
  34. 34. 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 webapps point of view  Changing the web server/application server is inevitable and therefore acceptable
  35. 35. 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
  36. 36. Deployment Status
  37. 37. Deployment Status Google  Enabled for all Google SSL traffic  On by default since Chrome 6
  38. 38. Deployment Status Google  Enabled for all Google SSL traffic  On by default since Chrome 6 CDNs/Service providers:  Cotendo
  39. 39. 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
  40. 40. 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...
  41. 41. Results
  42. 42. Yahoo! Homepage, over broadband network
  43. 43. Yahoo! homepage HTTP Broadband RTT = 20msPage Load: 1.23sec
  44. 44. Yahoo! homepage SPDY (via Cotendo) Broadband RTT = 20msPage Load: 1.21sec -2%
  45. 45. Amazon.com Homepage, over 3G network
  46. 46. Amazon.com Homepage HTTP 3G, AT&T RTT = 200+msPage Load: 12.50sec
  47. 47. Amazon.com Homepage SPDY (via Cotendo) 3G AT&T RTT = 200+msPage Load: 6.26sec -49%
  48. 48. HTTPS vs SPDY (Production)
  49. 49. Increasing Parallelism
  50. 50. Less is More - Conns, Bytes, Packets
  51. 51. 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
  52. 52. Cant We Address Latency & Security Separately?
  53. 53. Cant We Address Latency & Security Separately? No.
  54. 54. Cant 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%
  55. 55. How we tune today
  56. 56. 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
  57. 57. High Performance Web Sites 1.Make fewer HTTP requests 2.Use CDN 3.Add expires header 4.Gzip Components Du 5.Put stylesheets at the top 6.Put scripts at the bottom e 7.Avoid CSS expressions To 8.Make JS and CSS external HT 9.Reduce DNS lookups TP 10.Minify JS Li 11.Avoid redirects m 12.Remove duplicate scripts ita 13.Configure Etags tio 14.Make Ajax cacheable ns 15.Sharding domains !
  58. 58. Firetruck
  59. 59. Domain Sharding
  60. 60. Domain Sharding Pros:  Parallelism in HTTP  Cookieless domains for static content
  61. 61. Domain Sharding Pros:  Parallelism in HTTP  Cookieless domains for static content
  62. 62. 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
  63. 63. Reduce number of requests Inlining Spriting Data URLs Combining javascripts and CSS files Cons:  reduced cache efficiency  Complicated
  64. 64. New Class of FEO
  65. 65. 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!
  66. 66. Image Compression Number of Requests Transfer Size in KB Other HTML Other HTML 7.0 6.5 99 32 Scripts Scripts 119 13.0 Stylesheets Stylesheets 25 3.5 Images Images 55.0 415 Source: http://httparchive.org/trends.php?s=Top1000
  67. 67. In mobile even stronger! Number of Requests Transfer Size in KB Other HTML 2 Other 4 HTML 6 42 Scripts 7 Scripts Stilesheets 80 2 Images Images 228 31 Stilesheets 20 Source: http://mobile.httparchive.org/trends.php?s=Top1000
  68. 68. Lossy compression is the way to go! Billy Hoffman / Zoompf AP Photo/John Bazemore
  69. 69. Lossy-Compression is Not for Everythinghttp://www.flickr.com/photos/tracy_olson/61056391/
  70. 70. Progressive image compression http://images.sixrevisions.com/2010/12/01-02_baseline_vs_progressive.jpg
  71. 71. Client Server
  72. 72. Client Server Get HTML
  73. 73. Client Server
  74. 74. Client Server Get all objects
  75. 75. Client Server 20% 20% 20% 20% 20%
  76. 76. Client Server 80% 80% 80% 80% 80%
  77. 77. Summary
  78. 78.  SPDY actually delivers!
  79. 79.  SPDY actually delivers!  but we are still in the early phases
  80. 80.  SPDY actually delivers!  but we are still in the early phases  participate and be part of the solution
  81. 81.  SPDY actually delivers!  but we are still in the early phases  participate and be part of the solution
  82. 82.  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!
  83. 83.  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.
  84. 84.  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?
  85. 85.  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?
  86. 86.  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
  87. 87.  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
  88. 88.  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!
  89. 89. 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
  90. 90. Ido Safruti, ido@cotendo.comMike Belshe, mbelshe@google.com
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×