Successfully reported this slideshow.
Your SlideShare is downloading. ×

What HTTP/2.0 Will Do For You

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
Introduction to HTTP/2
Introduction to HTTP/2
Loading in …3
×

Check these out next

1 of 54 Ad

What HTTP/2.0 Will Do For You

Download to read offline

An overview of where HTTP/2.0 is at and what it might mean for how we deploy and operate the Web, from the chair of the IETF HTTPbis Working Group.

An overview of where HTTP/2.0 is at and what it might mean for how we deploy and operate the Web, from the chair of the IETF HTTPbis Working Group.

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Advertisement

Similar to What HTTP/2.0 Will Do For You (20)

Advertisement

What HTTP/2.0 Will Do For You

  1. 1. What HTTP/2.0 will* TO __ do for you Mark Nottingham http://www.mnot.net/ or, @mnot
  2. 2. * forward-looking statement ___ statement based on TECHNICA L A projected financial management expectations. A forward- looking statement involves risks with regard to the accuracy of assumptions underlying the projections. Discussions of these statements typically include words such as estimate, anticipate, project, and believe.
  3. 3. 1. Some recent history
  4. 4. IETF HTTPbis WG WHAT? to clarify RFC2616 and improve interop WHO? Roy Fielding, Julian Reschke WHO (2)? Apache, Mozilla, Chrome, IIS, Varnish, Squid, F5, Curl, ATS, IE, HAProxy... WHEN: Almost finished! WHEN (2): ... after FIVE YEARS :(
  5. 5. IETF HTTPbis WG (2) STRICTLY chartered to avoid making a new version of the protocol. Because EVERYBODY knows that’s not going to happen.
  6. 6. MEANWHILE
  7. 7. November 2009: Mike Belshe and Roberto Peon announce SPDY March 2011: Mike talks about SPDY to the HTTPbis WG at IETF80 ~April 2011: Chrome, Google start using SPDY March 2012: HTTPbis solicits proposals for new protocol work March 2012: Firefox 11 ships with SPDY (off by default) May 2012: Netcraft finds 339 servers that support SPDY June 2012: Nginx announces SPDY implementation July 2012: Akamai announces SPDY implementation Tuesday: HTTPbis re-chartered to work on HTTP/2.0, based on SPDY
  8. 8. 2. What is it?
  9. 9. NO change to HTTP semantics; it’s about how it gets onto the wire
  10. 10. Nothing new to see here
  11. 11. Not magic
  12. 12. 1.multiplexing 2.header compression 3.server push (?) 4.TLS (?)
  13. 13. 2.1 multiplexing
  14. 14. connection setup vanilla server client GE T /foo HTTP/1.0 One request K 200 O per TCP connection connection close OMG ITS SO SLOW
  15. 15. GE T /foo O K 200 HTTP/1.0 (with Keep-Alive) GE T /ba r able to reuse connections, avoid connection setup O K 200 GE T /ba z
  16. 16. GE T /foo O K 200 BUT it still blocks GE T /ba r one outstanding request at a time O K 200 GE T /ba z
  17. 17. GE T /foo GE T /ba r GE T /ba z O K 200 200 O K HTTP/1.1 OK 200 (with pipelining) multiple, ordered requests
  18. 18. GE T /foo GE T /ba r head-of-line blocking OK 200 Still serialised! K 2 00 O Large downloads / long “think” time can block other requests
  19. 19. The State of the Art • Use persistent connections (“keep-alives”) • Pipelining is getting a little deployment • Use multiple connections for parallelism • RFC2616 said “2”; HTTPbis says “reasonable” • Browsers use 4-8; bad people use more • Build lots of heuristics into browsers for connection reuse • Hope that it all works out
  20. 20. What’s so bad about that? • TCP is built for long-lived flows • More connections = shorter flows • Congestion control doesn’t have time to ramp up • Makes Buffer Bloat worse • Fairness (user to user, app to app) • How many connections is the best?
  21. 21. four at a time cascading waterfalls
  22. 22. GE T /foo GE T /ba r K 2 GE 00 T O /ba SPDY 2 00 O K z multiplexing GE T /a • one connection 20 0O K • many requests • prioritisation GE T /b • out of order OK 20 0 • interleaved GE T /c NO* QUEUING 0 OK 20
  23. 23. 2.2 header compression
  24. 24. GET / HTTP/1.1 Host: www.etsy.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.26.14 (KHTML, like Gecko) Version/6.0.1 Safari/536.26.14 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 DNT: 1 Accept-Language: en-us Accept-Encoding: gzip, deflate Cookie: uaid=uaid%3DVdhk5W6sexG-_Y7ZBeQFa3cq7yMQ%26_now%3D1325204464%26_slt %3Ds_LCLVpU%26_kid%3D1%26_ver%3D1%26_mac %3DlVnlM3hMdb3Cs3hqMVuk_dQEixsqQzUlNYCs9H_Kj8c.; user_prefs=1&2596706699&q0tPzMlJLaoEAA== Connection: keep-alive 525 bytes
  25. 25. GET /assets/dist/js/etsy.recent-searches.20121001205006.js HTTP/1.1 Host: www.etsy.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.26.14 (KHTML, like Gecko) Version/6.0.1 Safari/536.26.14 Accept: */* DNT: 1 Referer: http://www.etsy.com/ Accept-Language: en-us Accept-Encoding: gzip, deflate Cookie: autosuggest_split=1; etala=111461200.1476767743.1349274889.1349274889.1349274889.1.0; etalb=111461200.1.10.1349274889; last_browse_page=%2F; uaid=uaid%3DVdhk5W6sexG- _Y7ZBeQFa3cq7yMQ%26_now%3D1325204464%26_slt%3Ds_LCLVpU%26_kid%3D1%26_ver%3D1%26_mac %3DlVnlM3hMdb3Cs3hqMVuk_dQEixsqQzUlNYCs9H_Kj8c.; user_prefs=1&2596706699&q0tPzMlJLaoEAA== Connection: keep-alive 226 new bytes; 690 total
  26. 26. GET /assets/dist/js/jquery.appear.20121001205006.js HTTP/1.1 Host: www.etsy.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.26.14 (KHTML, like Gecko) Version/6.0.1 Safari/536.26.14 Accept: */* DNT: 1 Referer: http://www.etsy.com/ Accept-Language: en-us Accept-Encoding: gzip, deflate Cookie: autosuggest_split=1; etala=111461200.1476767743.1349274889.1349274889.1349274889.1.0; etalb=111461200.1.10.1349274889; last_browse_page=%2F; uaid=uaid%3DVdhk5W6sexG- _Y7ZBeQFa3cq7yMQ%26_now%3D1325204464%26_slt%3Ds_LCLVpU%26_kid%3D1%26_ver%3D1%26_mac %3DlVnlM3hMdb3Cs3hqMVuk_dQEixsqQzUlNYCs9H_Kj8c.; user_prefs=1&2596706699&q0tPzMlJLaoEAA== Connection: keep-alive 14 new bytes; 683 total
  27. 27. GET /assets/dist/js/bootstrap/username-suggester.20121001205006.js HTTP/1.1 Host: www.etsy.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.26.14 (KHTML, like Gecko) Version/6.0.1 Safari/536.26.14 Accept: */* DNT: 1 Referer: http://www.etsy.com/ Accept-Language: en-us Accept-Encoding: gzip, deflate Cookie: autosuggest_split=1; etala=111461200.1476767743.1349274889.1349274889.1349274889.1.0; etalb=111461200.1.10.1349274889; last_browse_page=%2F; uaid=uaid%3DVdhk5W6sexG- _Y7ZBeQFa3cq7yMQ%26_now%3D1325204464%26_slt%3Ds_LCLVpU%26_kid%3D1%26_ver%3D1%26_mac %3DlVnlM3hMdb3Cs3hqMVuk_dQEixsqQzUlNYCs9H_Kj8c.; user_prefs=1&2596706699&q0tPzMlJLaoEAA== Connection: keep-alive 28 new bytes; 698 total
  28. 28. • Four requests • 2,596 bytes total • Minimum three packets in most places • One for the HTML, two+ for assets • 1,797 redundant bytes
  29. 29. HTTP headers on a connection are highly similar
  30. 30. Request URI User-Agent Cookies Referer
  31. 31. Big req * many reqs / small IW = SLOW • Patrick’s test: • 83 asset requests • IW = 3 • ~1400 bytes of headers • Uncompressed: 7-8RT • Compressed (zlib): 1RT
  32. 32. 2.3 server push (?)
  33. 33. 2.4 TLS?
  34. 34. 3. What does it all mean?
  35. 35. HTTP/2.0 is going to change Web Engineering...
  36. 36. ... but not change HTTP APIs. Much.
  37. 37. Leaky Abstractions
  38. 38. Reduce Requests
  39. 39. • Image spriting - not necessary • CSS / JS can be in multiple files • HTTP APIs can be finer-grained without sacrificing performance • Third party content is an even bigger problem
  40. 40. Domain Sharding
  41. 41. • Multiplexing SHOULD make multiple connections unnecessary • Key is to get the TCP connection “warm” as quickly as possible, and keep it there
  42. 42. Header Optimisation
  43. 43. • Now, adding new headers is easy • Very small performance / latency / bandwidth impact • What should be in headers can be in headers • Content Negotiation might become interesting again
  44. 44. Predictability
  45. 45. Better Error Handling
  46. 46. Debugging will need Tools
  47. 47. Lots of tweaking • Prioritisation • When to Push • Flow Control
  48. 48. Transition Decisions • De-sharding • De-combining scripts • De-spriting • etc.
  49. 49. Guess what, Steve? Absurdly Fast Web Sites. Fast.
  50. 50. 4. What’s still wrong
  51. 51. 4.1 Security is hard
  52. 52. 4.2 TCP is awkward • In-order delivery = head-of-line blocking • Initial congestion window is small • Packet loss isn’t handled well
  53. 53. HTTP as the “Everything Protocol” ?
  54. 54. Some Links http://bit.ly/httpbis-home http://www.chromium.org/spdy http://www.mnot.net/

×