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

The Magic Behind HTTP/2

r31gN_
April 23, 2017

The Magic Behind HTTP/2

r31gN_

April 23, 2017
Tweet

More Decks by r31gN_

Other Decks in Technology

Transcript

  1. The magic behind HTTP/2

  2. @r31gN_ JS Instructor GDE

  3. None
  4. A brief history

  5. 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
  6. 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)
  7. HTTP/1.0 HTTP/1.1 HTTP/1.1 Pipelining

  8. 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
  9. Best practices DOWNSIDES • Fewer files ◦ Download and parse

    unnecessary content • Inline stuff ◦ Prevents caching • Domain sharding ◦ Each connection adds overhead ◦ Race conditions
  10. HTTP/2

  11. 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)
  12. None
  13. 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
  14. None
  15. None
  16. 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
  17. R A B W - 12 W - 4

  18. C A B W - 12 W - 4 R

    W - 1
  19. 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)
  20. 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)
  21. 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
  22. 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
  23. None
  24. https://github.com/http2/http2 -spec/wiki/Implementations

  25. Keep on smiling because you are the most beautiful people

    when you do.
  26. Q&A

  27. Thank you! @r31gN_