Blink: Intent to Remove: HTTP/2 and gQUIC server push

Primary eng (and PM) emails

las...@chromium.org, dsch...@chromium.org, b...@chromium.org, ians...@chromium.org

Summary

Remove the ability to receive, keep in memory, and use HTTP/2 and gQUIC push streams sent by the server.  Send SETTINGS_ENABLE_PUSH = 0 at the beginning of every HTTP/2 and gQUIC connection to request that servers not send them.

Background

HTTP/2 allows servers to “push” a resource that the client will likely need before the client actually requests it, see https://httpwg.org/specs/rfc7540.html#PushResources.  The specification allows the client to reject the pushed resource at its discretion.

gQUIC is a non-standard protocol supported by Google servers, Akamai, and Litespeed.  It also allows servers to push resources in a fashion very similar to HTTP/2.  gQUIC is being obsoleted by HTTP/3 and support will eventually be removed entirely.

HTTP/3 is an almost-RFC protocol that also defines server push, see https://quicwg.org/base-drafts/draft-ietf-quic-http.html#name-server-push.

Chrome currently supports handling push streams over HTTP/2 and gQUIC, and this intent is about removing support over both protocols.  Chrome does not support push over HTTP/3 and adding support is not on the roadmap.

Motivation

Almost five and a half years after the publication of the HTTP/2 RFC, server push is still extremely rarely used.  Over the past 28 days, 99.95% of HTTP/2 connections created by Chrome never received a pushed stream (Net.SpdyStreamsPushedPerSession), and 99.97% of connections never received a pushed stream that got matched with a request (Net.SpdyStreamsPushedAndClaimedPerSession).  These numbers are exactly the same as in June 2019.  In June 2018, 99.96% of HTTP/2 connections never received a pushed stream.  These numbers  indicate the lack of active efforts by server operators to increase push usage.  On top of this, less than 40% of received pushes are used, down from 63.51% two years ago.  The rest are invalid, never get matched to a request, or already in cache.

Server push is very difficult to use well.  Akamai publicly shared two studies showing that push over HTTP/2 either does not change performance or improves performance marginally when used with certain restrictions, see https://lists.w3.org/Archives/Public/ietf-http-wg/2019JulSep/0078.html.  However, these studies had been done more than a year ago and push usage data still does not indicate wide deployment even within Akamai’s network.  In light of this it is doubtful that smaller server operators have the resources to successfully deploy server push.

A contrasting result has been presented to the same IETF in 2018: a large experiment done by Chrome to measure the effect of server push on page load latency when using HTTP/2 showed that push increases latency at the long tail, see https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf.

As far as gQUIC goes, over the past 28 days, less than 1 out of 1,200,000 connections have seen any pushed streams.  We are not aware of any studies done on the effect of latency.

There is significant code complexity associated with Chromium supporting push: pushed requests have to be stored in an in-memory cache, looked up by URL across connections but only if the connection is authoritative for the request, matched by other parameters (method and other headers), and evicted after a timeout.  Running associated tests burden developers and infrastructure when developing unrelated features, and users bear the burden of increased binary size.  We believe that these outweigh the theoretical performance benefits.

Interoperability and Compatibility Risk

There is no compatibility risk.  Server push is meant as a performance optimization, a client is allowed to choose to reject any pushed streams.  In order to minimize wasted downlink capacity, Chromium would cancel pushed streams that a buggy server might open despite Chromium disabling server push by sending SETTINGS_ENABLE_PUSH = 0 in the initial SETTINGS frame.  Note however that in the experiment conducted two years ago no server was observed to send pushes when this setting was sent.

Firefox and Safari both support HTTP/2 push and we are not aware of any plans for removal.

Alternative implementation suggestion for web developers

It is recommended that servers use the <link rel="preload"> element to notify the client about subresources that it is expected to need.  Admittedly these resources will then need to be requested by the client, making them arrive 1 RTT later than a pushed resource would.  On the other hand, <link rel="preload"> allows the client to avoid fetching resources which are already cached.  Repeated efforts to analyze the latency gains of push found little or no benefit.

Because of limitations of HTTP/2 stream multiplexing, a server may normally only send <link rel="preload"> elements when the rest of the final headers are available, otherwise it would block other responses on the connection.  The 103 Early Hints status code (https://tools.ietf.org/html/rfc8297) is expected to provide better performance under certain circumstances by allowing information about resources that the client should request to be sent as soon as available and then making the connection available for carrying data on other streams until the final response is sent.  There is active effort to measure the potential latency gain of 103 Early Hints (compared to not using it, without using server push in either case), with the understanding that resources will be allocated to implementing it in Chromium in case data look promising.  See https://chromium.googlesource.com/chromium/src/+/master/docs/early-hints.md for more details.

It is interesting to note that server push has been used in ways other than originally intended.  One prominent example is to stream data from the server to the client, which will be better served by the upcoming WebTransport protocol.

Usage information from UseCounter

N/A: this network stack feature is not instrumented to use UseCounter.

Entry on the feature dashboard

https://www.chromestatus.com/feature/6302414934114304

from Hacker News https://ift.tt/3nge2wn