From Fast To SPDY

2,178 views
2,045 views

Published on

This talk was given with Ido Safruti of Cotendo on June 15, 2011 in Santa Clara. Ido did most of the work.

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,178
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
16
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

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

×