In a HTTP/2 World - DeccanRubyConf 2017

Editor's Notes

• #4: 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)
• #5: 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.
• #6: 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)
• #7: 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
• #8: 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
• #9: (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. )
• #10: 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
• #11: Common practices to get around browser limits to make assets download faster, bundling assets together (JS, CSS, images) to avoid multiple round trips
• #12: 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)
• #13: Return a static view, which can then fetch the remaining content when it’s ready (how most SPAs work)
• #14: 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. 
• #15: 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.
• #16: 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
• #17: 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.
• #18: 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
• #19: 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?
• #20: 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.
• #21: In contrast let’s see how HTTP/2 performs. All 256 tiles served at once. Less that a second on a 2 Mbps connection
• #22: 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
• #23: 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.
• #24: So should we continue with our existing best practices now that HTTP/2 is around
• #25: 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.
• #26: 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
• #29: Common web servers, application server, CDNs Akamai and Cloudflare
• #30: 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)
• #31: 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
• #32: 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
• #33: (don’t use in production, but good POC)
• #35: 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.
• #36: 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
• #37: 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