$30 off During Our Annual Pro Sale. View Details »

What HTTP/2.0 will* do for you

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.

Mark Nottingham

October 04, 2012
Tweet

More Decks by Mark Nottingham

Other Decks in Technology

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