The Magic Behind HTTP/2

Transcript

1. The magic behind HTTP/2
2. @r31gN_ JS Instructor GDE
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)
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
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
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_