What HTTP/2.0 will* do for you

HTTP/1.1 has been the predominant protocol of the Web (and much more) for more than a decade, but Mike Belshe and Roberto Peon’s SPDY proposal has quickly focused attention on doing something better.

As a result, the IETF HTTPbis Working Group has started working on HTTP/2.0, based upon SPDY. While the primary focus is on performance and network-friendliness, it’s already clear that HTTP/2.0 will change how we design, deploy and operate the Web, as well as expand what we use HTTP for even further.

This talk explores these effects, how we might take advantage of them, and potential problems that might arise.

Transcript

1. What HTTP/2.0 will*
   do for you
   Mark Nottingham
   http://www.mnot.net/
   or, @mnot
   TO
   __
   

   View Slide

2. forward-looking statement
   A projected financial statement based on
   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.
   *
   ___
   TECHNICAL
   

   View Slide

3. 1. Some recent history
   

   View Slide

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 :(
   

   View Slide

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.
   

   View Slide

6. MEANWHILE
   

   View Slide

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
   

   View Slide

8. 2. What is it?
   

   View Slide

9. NO change to HTTP semantics; it’s
   about how it gets onto the wire
   

   View Slide

10. Nothing new
    to see here
    

    View Slide

11. Not magic
    

    View Slide

12. 1.multiplexing
    2.header compression
    3.server push (?)
    4.TLS (?)
    

    View Slide

13. 2.1 multiplexing
    

    View Slide

14. GET /foo
    200 OK
    vanilla
    HTTP/1.0
    One request
    per TCP connection
    client
    server
    connection close
    connection setup
    OMG ITS SO SLOW
    

    View Slide

15. GET /foo
    GET /bar
    200 OK
    200 OK
    HTTP/1.0
    (with Keep-Alive)
    GET /baz
    able to reuse
    connections, avoid
    connection setup
    

    View Slide

16. GET /foo
    GET /bar
    200 OK
    200 OK
    BUT
    it still blocks
    GET /baz
    one outstanding
    request at a time
    

    View Slide

17. GET /foo
    GET /bar
    200 OK
    200 OK
    HTTP/1.1
    multiple, ordered
    requests
    (with pipelining)
    GET /baz
    200 OK
    

    View Slide

18. head-of-line
    blocking
    GET /foo
    GET /bar
    200 OK
    200 OK
    Still serialised!
    Large downloads /
    long “think” time can
    block other requests
    

    View Slide

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
    

    View Slide

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?
    

    View Slide

21. cascading waterfalls
    four at a time
    

    View Slide

22. SPDY
    multiplexing
    GET /foo
    GET /bar
    200 OK
    • one connection
    • many requests
    • prioritisation
    • out of order
    • interleaved
    GET /baz
    GET /a
    GET /b
    GET /c
    200 OK
    200 OK
    200 OK
    200 OK
    NO* QUEUING
    

    View Slide

23. 2.2 header compression
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

28. • Four requests
    • 2,596 bytes total
    • Minimum three packets in most places
    • One for the HTML, two+ for assets
    • 1,797 redundant bytes
    

    View Slide

29. HTTP headers on a
    connection are
    highly similar
    

    View Slide

30. Request URI
    User-Agent
    Cookies
    Referer
    

    View Slide

31. • Patrick’s test:
    • 83 asset requests
    • IW = 3
    • ~1400 bytes of headers
    • Uncompressed: 7-8RT
    • Compressed (zlib): 1RT
    Big req * many reqs / small IW = SLOW
    

    View Slide

32. 2.3 server push (?)
    

    View Slide

33. 2.4 TLS?
    

    View Slide

34. 3. What does it all mean?
    

    View Slide

35. HTTP/2.0 is going to
    change Web Engineering...
    

    View Slide

36. ... but not change
    HTTP APIs. Much.
    

    View Slide

37. Leaky Abstractions
    

    View Slide

38. Reduce Requests
    

    View Slide

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
    

    View Slide

40. Domain Sharding
    

    View Slide

41. • Multiplexing SHOULD make multiple
    connections unnecessary
    • Key is to get the TCP connection
    “warm” as quickly as possible, and
    keep it there
    

    View Slide

42. Header Optimisation
    

    View Slide

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
    

    View Slide

44. Predictability
    

    View Slide

45. Better Error
    Handling
    

    View Slide

46. Debugging will
    need Tools
    

    View Slide

47. Lots of tweaking
    • Prioritisation
    • When to Push
    • Flow Control
    

    View Slide

48. Transition Decisions
    • De-sharding
    • De-combining scripts
    • De-spriting
    • etc.
    

    View Slide

49. Guess
    what,
    Steve?
    Absurdly Fast
    Web Sites. Fast.
    

    View Slide

50. 4. What’s still wrong
    

    View Slide

51. 4.1 Security is hard
    

    View Slide

52. 4.2 TCP is awkward
    • In-order delivery = head-of-line blocking
    • Initial congestion window is small
    • Packet loss isn’t handled well
    

    View Slide

53. HTTP as the
    “Everything Protocol”
    ?
    

    View Slide

54. Some Links
    http://bit.ly/httpbis-home
    http://www.chromium.org/spdy
    http://www.mnot.net/
    

    View Slide