Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Magic Behind HTTP/2

April 23, 2017

The Magic Behind HTTP/2


April 23, 2017

More Decks by r31gN_

Other Decks in Technology


  1. HTTP/1.0 (year 1996) • Made a new connection for every

    request ◦ Overhead ◦ 3 packets for setup ◦ 4 packets for termination ◦ https://tools.ietf.org/search/rfc1945
  2. HTTP/1.1 (year 1997) • Persistent connections ◦ Reuse the connection

    for multiple requests ◦ Still one request at a time • Pipelined connections ◦ Multiple requests at a time ◦ Requests are served in FIFO order (slow requests are blocking) ◦ Recommendation not to use it (Chromium project)
  3. Best practices • Fewer files ◦ JS/CSS concatenation ◦ Image

    sprites • Inline stuff ◦ JS/CSS ◦ Data URI for images • Domain sharding ◦ ~ 6 connections per domain ◦ Share assets across multiple domains
  4. Best practices DOWNSIDES • Fewer files ◦ Download and parse

    unnecessary content • Inline stuff ◦ Prevents caching • Domain sharding ◦ Each connection adds overhead ◦ Race conditions
  5. HTTP/2 in one slide • Binary framing layer • Request/response

    multiplexing • Other features ◦ Prioritisation ◦ Flow control ◦ Server push • Only one TCP connection • Header compression (HPACK)
  6. Streams, messages, frames • Stream: bidirectional flow of bytes which

    may carry one or more messages • Message: a complete sequence of frames that map to a request/response • Frame: smallest unit of communication in HTTP/2, containing a frame header, which at a minimum identifies the stream to which the frame belongs
  7. Stream prioritisation • Each stream may be given an integer

    between 1 and 256 • Each stream may depend on other streams • The combination of dependencies and weights will result in a prioritisation tree • This is used to prioritise CPU/memory allocation
  8. Flow control • Mechanism to prevent the sender from overwhelming

    the receiver • ~ TCP Flow Control (but it was not granular enough) • HTTP/2 does not implement an algorithm, but provides building blocks for this ◦ Is directional ◦ Is credit based ◦ Cannot be disabled ◦ It is hop-by-hop (an intermediary node can decide other algorithms)
  9. Server push • Serve more than one response per request

    (even if client did not request specifically) • Server builds dependency graph based on referer header • Server push streams are initiated by the PUSH_PROMISE frame (contain the HTTP headers of the promised resource) • Client can opt to reject the stream (RST_STREAM frame) • This is an optimisation over HTTP/1.1 inlining assets strategy (which was always forced)
  10. HPACK compression format • Headers are now compressed (including cookies!)

    • Based on a shared compression context that both client and server understand (Huffman code) • Has a static and a dynamic table ◦ Static table is used for common HTTP header fields ◦ Dynamic table is initially empty, but gets progressively built
  11. Best practices • No more concatenation ◦ No more cache

    churn issues ◦ Only download what is needed • No more inlining ◦ Better caching • No more domain sharding ◦ Better resource utilisation
  12. Q&A