The Magic Behind HTTP/2

Transcript

1. The magic behind
   HTTP/2
   

   View Slide

2. @r31gN_
   JS Instructor
   GDE
   

   View Slide

3. View Slide

4. A brief history
   

   View Slide

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
   

   View Slide

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)
   

   View Slide

7. HTTP/1.0 HTTP/1.1 HTTP/1.1 Pipelining
   

   View Slide

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
   

   View Slide

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

   View Slide

10. HTTP/2
    

    View Slide

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)
    

    View Slide

12. View Slide

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
    

    View Slide

14. View Slide

15. View Slide

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
    

    View Slide

17. R
    A B
    W - 12 W - 4
    

    View Slide

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

    View Slide

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)
    

    View Slide

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)
    

    View Slide

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
    

    View Slide

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
    

    View Slide

23. View Slide

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

    View Slide

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

    View Slide

26. Q&A
    

    View Slide

27. Thank you!
    @r31gN_
    

    View Slide