In a HTTP/2 World - DeccanRubyConf 2017
•Download as PPTX, PDF•
1 like•216 views
Why HTTP/1.1 needs to be phased out and how to leverage HTTP/2 features for improved web development practices. Also, the state of Ruby and how to use the new protocol even though support is limited.
More Related Content
What's hot
What's hot (20)
Similar to In a HTTP/2 World - DeccanRubyConf 2017
Similar to In a HTTP/2 World - DeccanRubyConf 2017 (20)
Recently uploaded
Recently uploaded (20)
In a HTTP/2 World - DeccanRubyConf 2017
- 1. IN A HTTP/2 WORLD DOUGLAS VAZ, EQUAL EXPERTS DECCAN RUBYCONF 2017
- 2. 1. CURRENT STATE 2. PROBLEMS WITH HTTP/1.x 3. HTTP/2 (H2) FEATURES 4. RETHINKING CURRENT PRACTICES 5. ADOPTION, AND THE STATE OF RUBY
- 3. HTTP - A brief history 1997 - RFC 2068 (HTTP/1.1 first draft) 1999 - RFC 2616 (standard for HTTP/1.1) 2014 - RFC 7230 (6 part spec to revise HTTP/1.1) 1989 - 1996 - HTTP/1.0 1. Current State
- 5. SYN SYN/ACK ACK Client Server Request HTML Response Request CSS, JS, img * assets TCP Handshake 1. Current State
- 7. Problem 1: HTTP/1.x only allowed sequential request/response HTTP/1.x wasn’t designed for async requests. Pipelining allowed async requests but responses need to be consumed in order. Slow responses would block all later requests and reduce overall performance i.e. head-of- line blocking 2. Problems with HTTP/1.x
- 8. Workaround: Browsers disabled pipelining and used multiple connections 2. Problems with HTTP/1.x
- 9. Since only one requestconnection serviced at a given time, increasing bandwidth doesn’t reduce latency. Browsers open multiple connections for parallel requests, but are restricted to a max number per domain Problem 2: More bandwidth doesn’t mean lower latency http://httparchive.org/ 2. Problems with HTTP/1.x
- 10. Workaround: Domain sharding and asset concatenation to increase parallelism and reduce RTT 2. Problems with HTTP/1.x
- 11. SYN SYN/ACK ACK Client Server Request HTML Response Request CSS, JS, img * assets TCP Handshake Processing time Problem 3: Transfers are blocked while the server processes requests 2. Problems with HTTP/1.x
- 12. Workaround: tely with an intermediate state and serve content when ready via 2. Problems with HTTP/1.x
- 13. ession data stored in cookies are transferred as uncompressed headers and can add several kilo Problem 4: Protocol overhead due to headers 2. Problems with HTTP/1.x
- 14. Workaround: Most servers impose a limit on header size 2. Problems with HTTP/1.x
- 15. HTTP/2RFC 7540, May 2015 3. H2 Features
- 16. 3. H2 Features
- 17. H2 Key Features • Parallel request streams on a single connection • Binary protocol • Server push • Header compression • Stream prioritisation 3. H2 Features
- 18. Binary Framing Credits: Ilya Grigorik Frame Multiplexing 3. H2 Features
- 19. Parallel requests with HTTP/1.1 - Open multiple connections (ex. 6 in Chrome) - High request queue time 3. H2 Features
- 20. Parallel requests with HTTP/2 “Designed to reduce perceived latency” - Request multiple files in parallel on same connection - All requests are served immediately Based on Go’s HTTP/2 Demo 3. H2 Features
- 21. Credits: Ilya Grigorik HPACK Header Compression 3. H2 Features
- 22. HPACK compression performance 3. H2 Features
- 23. Current Practices Keep doing or stop? 4. Rethinking Practices
- 24. Domain Sharding https://www.keycdn.com/support/domain-sharding/ Don’t do this with HTTP/2 4. Rethinking Practices
- 25. Asset Concatenation http://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/webpack.html Not necessary anymore* 4. Rethinking Practices
- 26. HTTP/2 Implementations How do I use it? 5. Adoption, Implementation, Ruby
- 27. Browser Support 5. Adoption, Implementation, Ruby
- 28. Server Support 5. Adoption, Implementation, Ruby
- 29. Available Tools 5. Adoption, Implementation, Ruby • Chrome Dev Tools (inspect sessions and streams) • Wireshark (inspect frames and compressed headers) • nghttp2 (C library plus helpful binaries) • curl (needs to be build from source)
- 30. What about Ruby? + HTTP/2 = :`( 5. Adoption, Implementation, Ruby
- 31. Rack is not HTTP/2 compatible! • Rack is designed for request/response cycles • Communication with backend servers is not bi-directional or message oriented 5. Adoption, Implementation, Ruby
- 32. Option 1: igrigorik/http-2 gem install http-2 Limitations: 1. Not Rack compatible, hence can’t be used with Rails 2. Does not negotiate a fallback to HTTP/1.x Pure Ruby implementation of HTTP/2 5. Adoption, Implementation, Ruby
- 33. Option 2: H2 Enabled Proxy + Ruby backend Limitations: 1. Multiplexing won’t work 2. Server push requires additional configuration Proxy client requests via H20, nghttpx, Apache or nginx Enables header compression! 5. Adoption, Implementation, Ruby
- 34. Option 3: Server push via a CDN Hinted push: Use Link headers in the response Link: </css/styles.css>; rel=preload; as=style 5. Adoption, Implementation, Ruby
- 35. Option 4: Server push via an edge proxy Manual server push by configuring the edge proxy 5. Adoption, Implementation, Ruby
- 36. Caveats 1. Server might push files that are already cached 2. Server might push files not present on page 3. Stream prioritisation and cancelling might be affected by OS level TCP buffers 5. Adoption, Implementation, Ruby
- 38. References • Risks of pipelining: https://www.chromium.org/developers/design- documents/network-stack/http-pipelining • Design and technical goals: https://hpbn.co/http2/#design-and-technical-goals • Study on bandwidth vs latency: https://docs.google.com/a/chromium.org/viewer?a=v&pid=sites&srcid=Y2hyb2 1pdW0ub3JnfGRldnxneDoxMzcyOWI1N2I4YzI3NzE2 • Starting point for HTTP/2: https://http2.github.io/ • HTTP/2 for Ruby: https://www.speedshop.co/2016/01/07/what-http2-means- for-ruby-developers.html
Editor's Notes
- First used in 1989, along with other protocols such as Gopher. By 1995, HTTP had become the de fecto application layer protocol. This lead to standardisation by the Internet Engineering Task Force and HTTP/1.1 was published in ‘97 In 2014, HTTP/1.1 was further clarified with a 6 part draft (with regard to use of certain headers (Content-*, Referer, Location)
- While HTTP continued to remain the same, the internet was not the same playing field. The number and size of assets on a web page increased nearly exponentially. Almost a 10x increase from 2000 to 2016. It was clear that the protocol imposed restrictions that could no longer be dealt with at the application layer.
- How HTTP/1.x behaves. Starts with a 3 way TCP handshake to establish a connection. Browser requests an HTML page, parses it, and then requests for images, Javascript files, CSS files and other assets (one at a time over a connection)
- Typical HTTP/1.1 request and response format. Method, followed by path followed by protocol, followed by mandatory and optional headers. Response is similar. Starts with a status line, followed by a newline, headers and then data NOTE: TEXT BASED and human readable which makes it easy to construct by hand or debug
- HTTP/1.0 needed one connection per asset, HTTP/1.1 introduced keep-alive, but requests were synchronous. Also introduced pipelining which enabled sending multiple requests without waiting for a response, but responses needed to be consumed in order. If the first response is slow, all other later responses will be blocked. Badly implemented by proxies
- (The option to enable pipelining has been removed from Chrome, as there are known crashing bugs and known front-of-queue blocking issues. There are also a large number of servers and middleboxes that behave badly and inconsistently when pipelining is enabled. )
- Data bandwidth today is much greater than in early-2000s. Yet we couldn't take advantage of this because of the protocol limitations. Both transfer sizes and number of assets per page are growing (ex. CNN has 157 resources) Connection limit: could exhaust server and client limit
- Common practices to get around browser limits to make assets download faster, bundling assets together (JS, CSS, images) to avoid multiple round trips
- The network connection is blocked when the server is processing a request (browsers can’t request anymore on the connection, servers can’t switch to sending alternate files in the meantime)
- Return a static view, which can then fetch the remaining content when it’s ready (how most SPAs work)
- Since, HTTP is stateless, every request needs to convey the context. This is useful but can also be a huge overhead due to duplication of data on the wire However, the fact that all HTTP headers are transferred in plain text (without any compression), can lead to high overhead costs for each and every request, which can be a serious bottleneck for some applications and devices with limited resources.
- RFC 2616 (HTTP 1.1) does not define any limit on the size of the HTTP headers. in practice, many servers and proxies will try to enforce either an 8 KB or a 16 KB limit.
- In May 2015, HTTP/2 became a standard. A lot of vendors who had already supported SPDY due to Google’s influence quickly migrated to this spec
- Metaphor for HTTP/2’s design. Instead of placing an order one item at a time, you simply request for the entire meal upfront. You can also specify priorities such as wanting wine before the appetiser.
- A single TCP connection can have several logical connections, each transporting it’s own data. This is done by splitting packets into typed, interleaved frames, each having a unique identifier to indicate which stream it belongs to. H2 is a binary protocol, so not human readable and harder to debug. But much more efficient for a machine to process (think IoT with resource constraints) Server push is a feature where the server can send out data without an explicit request. This also indicated that streams are bidirectional in nature Headers are now sent in a frame at the start of a stream and the context is maintained for all frames in that stream. Additionally, the headers are compressed with a new algorithm called HPACK Clients can assign a priority weight to streams to fetch the more important files first (ex. CSS before images and fonts). Server doesn’t have to comply or can decide a default priority for different request types
- HTTP connection with 3 active streams. The colours indicate grouping of frames into a stream. Open a connection with HEADERS frame, send data with DATA frame. Streams can also be cancelled using a RST_STREAM header. How much of a difference does this make?
- A demonstration first constructed by the Golang team: The logo is tiled, comprising of 256 image tags on a web page. On page load, the browser requests for all 256 images in parallel. However, only one asset can be downloaded per connection and Chrome opens up 6 connections. That’s only 6 x 2 kb (12kbps) of a 2 Mbps connection.
- In contrast let’s see how HTTP/2 performs. All 256 tiles served at once. Less that a second on a 2 Mbps connection
- Header compression to reduce duplication with every request. HPACK is based on Huffman encoding with both a static and dynamic table. Header-value pairs sorted in descending order of frequency. The most frequently occurring header-value pair was given the smallest bit value. Apart from this static table, a connection can also negotiate a dynamic table which is used for lookups specific to that connection
- When I tested this on popular H2 enabled websites, the results were very positive. google.com shows an amazing 87% reduction in header size, which translates to lower bandwidth requirements.
- So should we continue with our existing best practices now that HTTP/2 is around
- Domain sharding is a practice of distributing assets among a set of domains to increase the number of connections to download in parallel. This is no longer needed cause parallel downloads can now be done with a single connection. Domain sharding is expensive cause of the DNS lookup plus handshake for each connection.
- Not necessary as a web optimisation. Easier to maintain cache consistency cause of separation. Keep stable vendor libs + frequently changing business code can be separated so that every small change does not invalidate the cache. Some bundling might be a good idea easy maintainability
- Common web servers, application server, CDNs Akamai and Cloudflare
- Chrome allows filtering on all active HTTP/2 sessions. Useful for viewing stream data Wireshark, network protocol analyser, has some support like decoding HPACK (but decoding streams is not straightforward) nghttp client to connect to H2 servers with HTTP Upgrade ALPN nghttpx -multi-threaded reverse proxy for HTTP/2, SPDY and HTTP/1.1 (mruby support available) Popular command line tool for fetching data from a server. Most OS distributions aren’t compiled with H2 capabilities (run with -V and look for HTTP2 under features)
- Turns out that Ruby has VERY limited support for HTTP/2. One of the reasons is that almost all Ruby web frameworks depend on Rack at the CGI level to talk to the web server
- The problem is, Rack is not HTTP/2 compatible. The architecture makes assumptions and hence cannot easily accommodate the new message oriented, bi-directional stream communication. There are still ways to use HTTP/2 with Ruby
- (don’t use in production, but good POC)
- Preload is a web optimisation technique to indicate assets which need an early fetch. Usually used via the <link> HTML tag. Some servers look for the LINK header in the application’s response and sends a PUSH_PROMISE frame followed by a DATA frame with actual content. Server can reject the push promise with a RST_STREAM frame Note: Server can only hint additional resource belonging to same origin policy.
- Similar to the CDN option, this relies on a configurable external proxy server to handle HTTP/2 requests. Advantage: Assets can be served via a server push while request is forwarded to application server for processing
- Cache digests is a proposed implementation to use a Bloom filter to inform the server of cached files Usually when CDN config and rendered page are out of sync. Managed by better engineering practices Not usually a worry but good to keep in mind