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/...
Did They Plan for That!?
HTTP/1.1
 Compression
 Headers
 Poor connection management
 Only one request can be done at a time (Half duplex)
 Par...
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.h...
Compression
Optional
Only for response body
~99% of browsers support
Particularly important on small pipes (mobile)
* http...
Compression
Optional
Only for response body
~99% of browsers support
Particularly important on small pipes (mobile)
15%-30...
Compression
Optional
Only for response body
~99% of browsers support
Particularly important on small pipes (mobile)
15%-30...
Compression
Optional
Only for response body
~99% of browsers support
Particularly important on small pipes (mobile)
15%-30...
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 Serv...
HTTP Connection - under the hood
TCP Connect + Request = 1.5 RTT
TCP Connect + SSL Connect + Request = 3.5 RTT
Client Serv...
HTTP Connection - under the hood
Request/Response = 0.5 RTT
TCP Connect + Request = 1.5 RTT
TCP Connect + SSL Connect + Re...
HTTP Connection - under the hood
Request/Response = 0.5 RTT
TCP Connect + Request = 1.5 RTT
TCP Connect + SSL Connect + Re...
HTTP Connection - under the hood
Request/Response = 0.5 RTT
TCP Connect + Request = 1.5 RTT
TCP Connect + SSL Connect + Re...
HTTP Connection - under the hood
Request/Response = 0.5 RTT
TCP Connect + Request = 1.5 RTT
TCP Connect + SSL Connect + Re...
HTTP Connection - under the hood
Request/Response = 0.5 RTT
TCP Connect + Request = 1.5 RTT
TCP Connect + SSL Connect + Re...
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 20...
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...
What is SPDY?
 Goal: Reduce Web Page Load time.
 Multiplexing
 Better utilize client connections
 Compression
 HTTP h...
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 = 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...
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 tool...
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
5.Put stylesheets a...
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 esta...
Reduce number of requests
 Inlining
 Spriting
 Data URLs
 Combining javascripts and CSS files
 Cons:
 reduced cache ...
New Class of FEO
Rethink your optimizations
 As rules change, your need to re-evaluate your best practices
 13 years is a long time! star...
Image Compression
HTML
6.5
Scripts
13.0
Stylesheets
3.5
Images
55.0
Other
7.0
HTML
32
Scripts
119
Stylesheets
25
Images
41...
In mobile even stronger!
HTML
42
Scripts
80
Stilesheets
20
Images
228
Other
6
HTML
4
Scripts
7
Stilesheets
2
Images
31
Oth...
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 ...
 SPDY actually delivers!
 but we are still in the early phases
 participate and be part of the solution
 Rules CAN be ...
 SPDY actually delivers!
 but we are still in the early phases
 participate and be part of the solution
 Rules CAN be ...
 SPDY actually delivers!
 but we are still in the early phases
 participate and be part of the solution
 Rules CAN be ...
 SPDY actually delivers!
 but we are still in the early phases
 participate and be part of the solution
 Rules CAN be ...
 SPDY actually delivers!
 but we are still in the early phases
 participate and be part of the solution
 Rules CAN be ...
 SPDY actually delivers!
 but we are still in the early phases
 participate and be part of the solution
 Rules CAN be ...
Measurement - Proving us Right
 No 3rd party tools (yet)!
 Chrome developer tools
 not good for large scale data...
 w...
Ido Safruti, ido@cotendo.com
Mike Belshe, mbelshe@google.com
From Fast to SPDY - Velocity 2011
From Fast to SPDY - Velocity 2011
From Fast to SPDY - Velocity 2011
Upcoming SlideShare
Loading in...5
×

From Fast to SPDY - Velocity 2011

465

Published on

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

Published in: Technology
2 Comments
0 Likes
Statistics
Notes
  • 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.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • what about data, does SPDY requires more data duo to no caching over SSL? does it affects the costs of using 3G ?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Views
Total Views
465
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
2
Likes
0
Embeds 0
No embeds

No notes for slide

From Fast to SPDY - Velocity 2011

  1. 1. From Fast to SPDY Ido Safruti, Mike Belshe,
  2. 2. SPDY
  3. 3. SPDYee
  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. Compression Optional Only for response body ~99% of browsers support * http://code.google.com/speed/articles/web-metrics.html + Cotendo measurements
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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
  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 Request/Response = 0.5 RTT TCP Connect + Request = 1.5 RTT TCP Connect + SSL Connect + Request = 3.5 RTT Client Server
  27. 27. 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 }
  28. 28. 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 } }
  29. 29. 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
  30. 30. 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
  31. 31. 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
  32. 32. http://desktopsecuritysoftwareguide.com/wp-content/uploads/2010/04/Padlock.jpg Security is optional
  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 webapp's 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 = 20ms Page Load: 1.23sec
  44. 44. Yahoo! homepage SPDY (via Cotendo) Broadband RTT = 20ms Page Load: 1.21sec -2%
  45. 45. Amazon.com Homepage, over 3G network
  46. 46. Page Load: 12.50sec Amazon.com Homepage HTTP 3G,AT&T RTT = 200+ms
  47. 47. Amazon.com Homepage SPDY (via Cotendo) 3G AT&T RTT = 200+ms Page 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. Can't We Address Latency & Security Separately?
  53. 53. Can't We Address Latency & Security Separately? No.
  54. 54. 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%
  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 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!
  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 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
  67. 67. 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
  68. 68. Lossy compression is the way to go! Billy Hoffman / Zoompf AP Photo/John Bazemore
  69. 69. http://www.flickr.com/photos/tracy_olson/61056391/ Lossy-Compression is Not for Everything
  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. 20% Client Server 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.com Mike Belshe, mbelshe@google.com

×