HTTP/2 Server Push

Last updated

HTTP/2 Server Push is an optional [1] feature of the HTTP/2 and HTTP/3 network protocols that allows servers to send resources to a client before the client requests them. Server Push is a performance technique aimed at reducing latency by sending resources to a client preemptively before it knows they will be needed. [2] In practice, Server Push frequently results in wasted bandwidth because the server rarely knows which resources are already loaded by the client and transmits the same resource multiple times, resulting in slowdowns if the resources being pushed compete for bandwidth with resources that were requested. [3]

Contents

HTTP/2 Server Push is not a notification mechanism from server to client. Instead, pushed resources are used by the client when it may have otherwise produced a request to get the resource anyway. [4] [5]

History

On May 14, 2015, HTTP/2 was standardized by RFC   7540, ratified as a Proposed Standard. The document includes section 8.2 entitled "Server Push" which introduced the concept to the protocol as an optional extension. Google Chrome 40 became the first browser supporting the final standardized HTTP/2 version, including the optional Server Push. [6]

In February 2018, Nginx 1.13.9 was released with optional support for HTTP/2 Server Push. [7]

In November 2020, Google announced its intent to remove Server Push from Google Chrome implementation of HTTP/2 and gQUIC (which later evolved into HTTP/3). [8]

In October 2022, Google announced their intent to remove Server Push from Google Chrome citing the poor performance of the extension in practice, lack of use and better alternatives. Chrome 106 became the first release disabling Server Push by default. [9]

Protocol

Unlike HTTP/1.1, HTTP/2 can multiplex multiple streams on one TCP connection. Server Push allows the server to open new streams by sending PUSH_PROMISE frames, in order to send the client resources it expects will be needed. A PUSH_PROMISE frame is similar to a GET request, but sent by the server. A client may choose to reject the push by sending an RST_STREAM frame, for example if it already has the resource cached; if it does not, it will store the pushed data in a cache associated with the connection which will be consulted before a request is sent down that connection. Clients can also request that servers not send server pushes using a SETTINGS frame. The specification itself does not specify how servers choose what to push: a webserver might send pushes to clients only on their first visit, to avoid redundantly sending cached resources. [10] [11] [12]

Implementations

SoftwareFirst supporting versionLast supporting version
Nginx Server1.13.9 (February 2018) [7] 1.25.1 (June 2023) [13]
LiteSpeed Server5.2Still supported, but deprecated [14] [ better source needed ]
Google Chrome Client40 (May 2015)106 (September 2022) [3] [9] [15]
Firefox Client?Still supported[ citation needed ]

Related Research Articles

The Domain Name System (DNS) is a hierarchical and distributed naming system for computers, services, and other resources in the Internet or other Internet Protocol (IP) networks. It associates various information with domain names assigned to each of the associated entities. Most prominently, it translates readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols. The Domain Name System has been an essential component of the functionality of the Internet since 1985.

<span class="mw-page-title-main">HTTP</span> Application protocol for distributed, collaborative, hypermedia information systems

The Hypertext Transfer Protocol (HTTP) is an application layer protocol in the Internet protocol suite model for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser.

<span class="mw-page-title-main">Web server</span> Computer software that distributes web pages

A web server is computer software and underlying hardware that accepts requests via HTTP or its secure variant HTTPS. A user agent, commonly a web browser or web crawler, initiates communication by making a request for a web page or other resource using HTTP, and the server responds with the content of that resource or an error message. A web server can also accept and store resources sent from the user agent if configured to do so.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

In the context of an HTTP transaction, basic access authentication is a method for an HTTP user agent to provide a user name and password when making a request. In basic HTTP authentication, a request contains a header field in the form of Authorization: Basic <credentials>, where <credentials> is the Base64 encoding of ID and password joined by a single colon :.

<span class="mw-page-title-main">HTTP pipelining</span>

HTTP pipelining is a feature of HTTP/1.1, which allows multiple HTTP requests to be sent over a single TCP connection without waiting for the corresponding responses. HTTP/1.1 requires servers to respond to pipelined requests correctly, with non-pipelined but valid responses even if server does not support HTTP pipelining. Despite this requirement, many legacy HTTP/1.1 servers do not support pipelining correctly, forcing most HTTP clients to not use HTTP pipelining.

Push technology, also known as server push, refers to a method of communication on the Internet where the initial request for a transaction is initiated by the server, rather than the client. This approach is different from the more commonly known "pull" method, where information transmission is requested by the receiver or client.

<span class="mw-page-title-main">HTTP referer</span> HTTP header field

In HTTP, "Referer" is an optional HTTP header field that identifies the address of the web page, from which the resource has been requested. By checking the referrer, the server providing the new web page can see where the request originated.

<span class="mw-page-title-main">HTTP persistent connection</span> Using a single TCP connection to send and receive multiple HTTP requests/responses

HTTP persistent connection, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using a single TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new connection for every single request/response pair. The newer HTTP/2 protocol uses the same idea and takes it further to allow multiple concurrent requests/responses to be multiplexed over a single connection.

The Online Certificate Status Protocol (OCSP) stapling, formally known as the TLS Certificate Status Request extension, is a standard for checking the revocation status of X.509 digital certificates. It allows the presenter of a certificate to bear the resource cost involved in providing Online Certificate Status Protocol (OCSP) responses by appending ("stapling") a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA, with the aim of improving both security and performance.

HTTP Live Streaming is an HTTP-based adaptive bitrate streaming communications protocol developed by Apple Inc. and released in 2009. Support for the protocol is widespread in media players, web browsers, mobile devices, and streaming media servers. As of 2022, an annual video industry survey has consistently found it to be the most popular streaming format.

SPDY is an obsolete open-specification communication protocol developed for transporting web content. SPDY became the basis for HTTP/2 specification. However, HTTP/2 diverged from SPDY and eventually HTTP/2 subsumed all usecases of SPDY. After HTTP/2 was ratified as a standard, major implementers, including Google, Mozilla, and Apple, deprecated SPDY in favor of HTTP/2. Since 2021, no modern browser supports SPDY.

<span class="mw-page-title-main">WebSocket</span> Computer network protocol

WebSocket is a computer communications protocol, providing simultaneous two-way communication channels over a single Transmission Control Protocol (TCP) connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011. The current specification allowing web applications to use this protocol is known as WebSockets. It is a living standard maintained by the WHATWG and a successor to The WebSocket API from the W3C.

<span class="mw-page-title-main">HTTP/1.1 Upgrade header</span> HTTP header field introduced in HTTP/1.1

The Upgrade header field is an HTTP header field introduced in HTTP/1.1. In the exchange, the client begins by making a cleartext request, which is later upgraded to a newer HTTP protocol version or switched to a different protocol. A connection upgrade must be requested by the client; if the server wants to enforce an upgrade it may send a 426 Upgrade Required response. The client can then send a new request with the appropriate upgrade headers while keeping the connection open.

HTTP/2 is a major revision of the HTTP network protocol used by the World Wide Web. It was derived from the earlier experimental SPDY protocol, originally developed by Google. HTTP/2 was developed by the HTTP Working Group of the Internet Engineering Task Force (IETF). HTTP/2 is the first new version of HTTP since HTTP/1.1, which was standardized in RFC 2068 in 1997. The Working Group presented HTTP/2 to the Internet Engineering Steering Group (IESG) for consideration as a Proposed Standard in December 2014, and IESG approved it to publish as Proposed Standard on February 17, 2015. The HTTP/2 specification was published as RFC 7540 on May 14, 2015.

CRIME is a security vulnerability in HTTPS and SPDY protocols that utilize compression, which can leak the content of secret web cookies. When used to recover the content of secret authentication cookies, it allows an attacker to perform session hijacking on an authenticated web session, allowing the launching of further attacks. CRIME was assigned CVE-2012-4929.

QUIC is a general-purpose transport layer network protocol initially designed by Jim Roskind at Google, implemented, and deployed in 2012, announced publicly in 2013 as experimentation broadened, and described at an IETF meeting. QUIC is used by more than half of all connections from the Chrome web browser to Google's servers. Microsoft Edge, Firefox and Safari support it.

HTTP/3 is the third major version of the Hypertext Transfer Protocol used to exchange information on the World Wide Web, complementing the widely-deployed HTTP/1.1 and HTTP/2. Unlike previous versions which relied on the well-established TCP, HTTP/3 uses QUIC, a multiplexed transport protocol built on UDP. On 6 June 2022, IETF published HTTP/3 as a Proposed Standard in RFC 9114.

References

  1. ↑ Belshe, M.; Peon, R.; Thomson, M. (May 2015). Thomson, M (ed.). "Hypertext Transfer Protocol Version 2 (HTTP/2)". doi: 10.17487/RFC7540 . A client can request that server push be disabled{{cite journal}}: Cite journal requires |journal= (help)
  2. ↑ Staff, Ars (2015-02-18). "HTTP/2 finished, coming to browsers within weeks". Ars Technica. Retrieved 2023-01-12.
  3. 1 2 "Intent to Remove: HTTP/2 and gQUIC server push". Google Groups . 2020-11-11. Archived from the original on 2021-11-28. Retrieved 2022-04-12.
  4. ↑ "HTTP/2 server configurations". HTTP/2 Space. Archived from the original on 2022-03-27. Retrieved 2019-03-30.
  5. ↑ "Server Push". Hypertext Transfer Protocol Version 2 (HTTP/2). Internet Engineering Task Force. May 2015. p. 60. sec. 8.2. doi: 10.17487/RFC7540 . RFC 7540. Archived from the original on 2022-04-04. Retrieved 2015-05-06.
  6. ↑ "Google announces SPDY's coming demise as HTTP/2 approaches". Ars Technica. 2015-02-10. Retrieved 2023-07-30.
  7. 1 2 "Changes with nginx 1.14.2". Nginx . 2018-12-04. Archived from the original on 2022-04-07.
  8. ↑ Lassey, Brad (2020-11-12). "Intent to Remove: HTTP/2 and gQUIC server push". Blink mailing list. Retrieved 2023-11-20.
  9. 1 2 "Removing HTTP/2 Server Push from Chrome". Chrome Developers. 2022-08-18. Retrieved 2023-07-30.
  10. ↑ "HTTP/1.1 vs HTTP/2: What's the Difference?". DigitalOcean. 2022-03-17. Retrieved 2023-11-20.
  11. ↑ "Introducing HTTP/2 Server Push with NGINX 1.13.9". Nginx. 2018-02-20. Retrieved 2023-11-20.
  12. ↑ "Announcing Support for HTTP/2 Server Push". 2016-04-28. Retrieved 2023-11-20.
  13. ↑ "Changes with nginx 1.25.1". Nginx . 2023-06-13. Retrieved 2023-07-12.
  14. ↑ "Page Optimization". LiteSpeed Documentation. Retrieved 2023-07-21.
  15. ↑ "Remove HTTP/2 push". chromestatus.com. 2022-10-31. Retrieved 2023-07-12.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.