The magic behind HTTP/2 

@r31gN_ JS Instructor GDE 

No content

A brief history 

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 

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) 

HTTP/1.0 HTTP/1.1 HTTP/1.1 Pipelining 

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 

Best practices DOWNSIDES ● Fewer files ○ Download and parse unnecessary content ● Inline stuff ○ Prevents caching ● Domain sharding ○ Each connection adds overhead ○ Race conditions 

HTTP/2 

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) 

No content

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 

No content

No content

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 

R A B W - 12 W - 4 

C A B W - 12 W - 4 R W - 1 

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) 

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) 

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 

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 

No content

https://github.com/http2/http2 -spec/wiki/Implementations 

Keep on smiling because you are the most beautiful people when you do. 

Q&A 

Thank you! @r31gN_