1 / 24

Web Server Design Week 15- HTTP/2 & HTTP/3

Web Server Design Week 15- HTTP/2 & HTTP/3. Old Dominion University Department of Computer Science CS 431/531 Fall 2018 Michael L. Nelson < mln@cs.odu.edu > 2018- 12-05. HTTP/1.1 is awesome – you can ’ t argue with its deployed footprint. But there are well-known performance limitations.

davischristine
Download Presentation

Web Server Design Week 15- HTTP/2 & HTTP/3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Web Server DesignWeek 15- HTTP/2 & HTTP/3 Old Dominion University Department of Computer Science CS 431/531 Fall 2018 Michael L. Nelson <mln@cs.odu.edu> 2018-12-05

  2. HTTP/1.1 is awesome – you can’t argue with its deployed footprint.But there are well-known performance limitations.

  3. HTTP is not a good fit for TCP • TCP is designed for long-lived, bulk transfers • High-handshake costs, TLS adds even more to startup costs • HTTP requests are short and bursty • Parallelism needed, but: • Pipelining has problems with head-of-line-blocking, recovering from failures • More TCP connections, more client+server resources to manage the sockets, bandwidth consumed by TCP overhead • In practice, browsers limit to six concurrent connections

  4. Parallelism Is Needed Because of Page Bloat From: https://www.webbloatscore.com/ See also: https://httparchive.org/reports/state-of-the-web

  5. Parallelism Limits In Practice From: https://hpbn.co/http1x/

  6. HTTP Headers: Metadata >> Data Here, 15 bytes of json + 352 bytes of request and response headers From: https://hpbn.co/http2/

  7. HTTP/1.1 optimizations

  8. Image Sprites Send one large image of all flags, use CSS to “cut out” the flag you need From: https://daniel.haxx.se/http2/

  9. Inlining & Concatenation • Inlining: send small images as base64 https://en.wikipedia.org/wiki/Data_URI_scheme • Concatenation: put all of your .js/.css files into a single, large .js/.css file • Probably sends more than you need • Small changes in one file means changes in the entire file

  10. Domain Sharding Six connections per domain, But with the overhead of additional DNS lookups. From: https://daniel.haxx.se/http2/

  11. Evolution from SPDY to HTTP/2 • November 2009: Google begins work on SPDY to address performance limitations of HTTP/1.1 • September 2010: SPDY supported in Chrome • January 2011: SPDY deployed for all Google services • March 2012: Twitter supports SPDY • March 2012: Call for proposals for HTTP/2 • June 2012: NGINX supports SPDY • July 2012: Facebook announces planned support for SPDY • November 2012: First draft of HTTP/2 (based on SPDY) • August 2014: HTTP/2 draft-17 and HPACK draft-12 are published • August 2014: Working Group last call for HTTP/2 • February 2015: IESG approved HTTP/2 and HPACK drafts • May 2015: RFC 7540 (HTTP/2) and RFC 7541 (HPACK) are published Collected from: https://en.wikipedia.org/wiki/SPDY, https://hpbn.co/http2/

  12. Google Deprecates SPDY “HTTP/2's primary changes from HTTP/1.1 focus on improved performance. Some key features such as multiplexing, header compression, prioritization and protocol negotiation evolved from work done in an earlier open, but non-standard protocol named SPDY. Chrome has supported SPDY since Chrome 6, but since most of the benefits are present in HTTP/2, it’s time to say goodbye. We plan to remove support for SPDY in early 2016, and to also remove support for the TLS extension named NPN in favor of ALPN in Chrome at the same time. Server developers are strongly encouraged to move to HTTP/2 and ALPN. We’re happy to have contributed to the open standards process that led to HTTP/2, and hope to see wide adoption given the broad industry engagement on standardization and implementation. “ Quoted in: https://hpbn.co/http2/ Original: https://blog.chromium.org/2015/02/hello-http2-goodbye-spdy.html

  13. High-level semantics of HTTP don’t change in HTTP/2, but the method of packaging and transport do.

  14. Binary Framing Layer No more hand-crafted telnet sessions – boo!!!!! From: https://hpbn.co/http2/

  15. Streams, Messages, Frames Stream: bi-directional connection, with 1 or more messages Message: logically complete request or response Frame: typed, atomic unit of communication From: https://hpbn.co/http2/

  16. Request & Response Multiplexing • Interleave multiple requests in parallel without blocking on any one • Interleave multiple responses in parallel without blocking on any one • Use a single connection to deliver multiple requests and responses in parallel • Remove unnecessary HTTP/1.x workarounds (such as concatenated files, image sprites, and domain sharding) • Deliver lower page load times by eliminating unnecessary latency and improving utilization of available network capacity Note: frames cannot be received out of order! From: https://hpbn.co/http2/

  17. Stream Dependencies & Weights A gets ¾ of bandwidth, B gets ¼ A & B are dependent on the “root” stream (i.e., no dependencies) C depends on D, service D first (weights trumped by dependency) D before C, C before A & B, weight A & B as before D before C, C & E equally Before A & B, weight A & B as before From: https://hpbn.co/http2/

  18. Server Push: 1 Request, N Responses • See discussion of HTTP/2 push in: • https://daniel.haxx.se/blog/2018/11/11/http-3/ Conceptually similar to inlining, rel=“preload”, rel=“prefetch”, etc. Can only push with same-origin policy. From: https://hpbn.co/http2/

  19. Header Repetitiveness Allows Compression Note: headers beginning with “:” are “pseudo-headers” (RFC 7540, 8.1.2.1); or “things-that-should-have-been-headers-in-HTTP/1.1” Pseudo-headers have to be listed before real headers. From: https://hpbn.co/http2/

  20. HTTP/1.1  HTTP/2 Upgrade Note: “h2” = HTTP/2 over TLS “h2c” = HTTP/2 over clear text TCP From: https://hpbn.co/http2/

  21. 9 Byte Frame Header Note: frames cannot be received out of order! Stream id, but not frame id. • Header Types: • DATA - Used to transport HTTP message bodies • HEADERS - Used to communicate header fields for a stream • PRIORITY - Used to communicate sender-advised priority of a stream • RST_STREAM - Used to signal termination of a stream • SETTINGS - Used to communicate configuration parameters for the connection • PUSH_PROMISE - Used to signal a promise to serve the referenced resource • PING - Used to measure the roundtrip time and perform "liveness" checks • GOAWAY - Used to inform the peer to stop creating streams for current connection • WINDOW_UPDATE - Used to implement flow stream and connection flow control • CONTINUATION - Used to continue a sequence of header block fragments From: https://hpbn.co/http2/

  22. Example Binary HTTP/2 Request From: https://hpbn.co/http2/

  23. HTTP/3 Network Stack HTTP/2 optimizes within TCP context (e.g., binary, streams & frames), HTTP/3 replaces TCP From: https://daniel.haxx.se/blog/2018/11/26/http3-explained/

  24. HTTP/3 • “HTTP-over-QUIC” was just recently renamed “HTTP/3” (Nov 2018) • https://daniel.haxx.se/blog/2018/11/11/http-3/ • Not really deployed yet, still in development • Major changes: • Streams are moved from the HTTP layer to the QUIC layer • HTTP/2 fixes HTTP head-of-line blocking, but not TCP head-of-line blocking (i.e., streams in TCP can still be held up by dropped TCP packets) • Since streams are independent, header compression changes • There is no clear-text version of HTTP/3 (integral TLS 1.3) • QUIC has faster handshakes than TCP + TLS Evolving document: https://daniel.haxx.se/blog/2018/11/26/http3-explained/

More Related