HTTP/2 (originally namedHTTP/2.0) is a major revision of theHTTP network protocol used by theWorld Wide Web. It was derived from the earlier experimentalSPDY protocol, originally developed byGoogle.[1][2] HTTP/2 was developed by the HTTP Working Group (also called httpbis, where "bis" means "twice" in Latin) of theInternet Engineering Task Force (IETF).[3][4][5] HTTP/2 is the first new version of HTTP since HTTP/1.1, which was standardized inRFC2068 in 1997. The Working Group presented HTTP/2 to theInternet Engineering Steering Group (IESG) for consideration as a Proposed Standard in December 2014,[6][7] and IESG approved it to publish as Proposed Standard on February 17, 2015 (and was updated in February 2020 in regard to TLS 1.3 and again in June 2022). The initial HTTP/2 specification was published as RFC 7540 on May 14, 2015.[8]
The standardization effort was supported by theChrome,Opera,Firefox,Internet Explorer 11,Safari,Amazon Silk, andEdge browsers. Most major browsers had added HTTP/2 support by the end of 2015.[9] About 97% of web browsers used have the capability (and 100% of "tracked desktop" web browsers).[9] As of July 2023[update], 36% (after topping out at just over 50%) of the top 10 million websites support HTTP/2.[10]
Its successor isHTTP/3, a major revision that builds on the concepts established by HTTP/2.[2][11][9][12]
The changes do not require any changes to how existing web applications work, but new applications can take advantage of new features for increased speed.[13] HTTP/2 leaves all of HTTP/1.1's high-level semantics, such asmethods,status codes,header fields, andURIs, the same. What is new is how the data is framed and transported between the client and the server.[13]
Websites that are efficient minimize the number of requests required to render an entire page byminifying (reducing the amount of code and packing smaller pieces of code into bundles, without reducing its ability to function) resources such as images and scripts. However, minification is not necessarily convenient nor efficient and may still require separate HTTP connections to get the page and the minified resources. HTTP/2 allows the server to "push" content, that is, to respond with data for more queries than the client requested. This allows the server to supply data it knows a web browser will need to render a web page, without waiting for the browser to examine the first response, and without the overhead of an additional request cycle.[14]
Additional performance improvements in the first draft of HTTP/2 (which was a copy of SPDY) come frommultiplexing of requests and responses to avoid some of thehead-of-line blocking problem in HTTP 1 (even whenHTTP pipelining is used), headercompression, and prioritization of requests.[15] However, as HTTP/2 runs on top of a single TCP connection, there is still potential for head-of-line blocking to occur if TCP packets are lost or delayed in transmission.[16]HTTP/2 no longer supports HTTP/1.1'schunked transfer encoding mechanism, as it provides its own, more efficient mechanisms for data streaming.[17]
SPDY (pronounced like "speedy") was a previous HTTP-replacement protocol developed by a research project spearheaded byGoogle.[18] Primarily focused on reducing latency, SPDY uses the same TCP pipe but different protocols to accomplish this reduction. The basic changes made to HTTP/1.1 to create SPDY included "true request pipelining without FIFO restrictions, message framing mechanism to simplify client and server development, mandatory compression (including headers), priority scheduling, and even bi-directional communication".[19]
The HTTP Working Group considered Google's SPDY protocol,Microsoft'sHTTP Speed+Mobility proposal (SPDY based),[18] and Network-Friendly HTTP Upgrade.[20] In July 2012,Facebook provided feedback on each of the proposals and recommended HTTP/2 be based on SPDY.[21] The initial draft of HTTP/2 was published in November 2012 and was based on a straight copy of SPDY.[22]
The biggest difference between HTTP/1.1 and SPDY was that each user action in SPDY is given a "stream ID", meaning there is a single TCP channel connecting the user to the server. SPDY split requests into either control or data, using a "simple to parse binary protocol with two types of frames".[19][23] SPDY showed evident improvement over HTTP, with a new page load speedup ranging from 11% to 47%.[24]
The development of HTTP/2 used SPDY as a jumping-off point. Among the many detailed differences between the protocols, the most notable is that HTTP/2 uses a fixedHuffman code-based header compression algorithm, instead of SPDY's dynamic stream-based compression. This helps to reduce the potential forcompression oracle attacks on the protocol, such as theCRIME attack.[23]
On February 9, 2015, Google announced plans to remove support for SPDY in Chrome in favor of support for HTTP/2.[25] This took effect starting with Chrome 51.[26][27]
HTTP/2 is defined for both HTTP URIs (without TLSencryption, a configuration which is abbreviated ash2c) and HTTPS URIs (over TLS usingALPN extension[45] whereTLS 1.2 or newer is required, a configuration which is abbreviated ash2).
Although the standard itself does not require usage of encryption,[46] all major client implementations (Chrome, Edge, Firefox,[47] Internet Explorer, Opera, Safari) have stated they will only support HTTP/2 over TLS, which makes encryptionde facto mandatory.[48]
TheFreeBSD andVarnish developerPoul-Henning Kamp asserts that the standard was prepared on an unrealistically short schedule, ruling out any basis for the new HTTP/2 other than the SPDY protocol and resulting in other missed opportunities for improvement. Kamp criticizes the protocol itself for being inconsistent and having needless, overwhelming complexity. He also states that the protocol violates theprotocol layering principle, for example by duplicating flow control that belongs in the transport layer (TCP). He also suggested that the new protocol should have removedHTTP Cookies, introducing a breaking change.[49]
Initially, some members[who?] of the Working Group tried to introduce an encryption requirement in the protocol. This faced criticism.
Critics stated that encryption has non-negligible computing costs and that many HTTP applications actually have no need for encryption and their providers have no desire to spend additional resources on it. Encryption proponents have stated that this encryption overhead is negligible in practice.[50]Poul-Henning Kamp has criticized the IETF for hastily standardizing Google's SPDY prototype as HTTP/2 due to political considerations.[49][51][52] The criticism of the agenda of mandatory encryption within the existing certificate framework is not new, nor is it unique to members of the open-source community – aCisco employee stated in 2013 that the present certificate model is not compatible with small devices like routers, because the present model requires not only annual enrollment and remission of non-trivial fees for each certificate, but must be continually repeated on an annual basis.[53] In the end the Working Group did not reach consensus over the mandatory encryption,[46] although most client implementations require it, which makes encryption ade facto requirement.
The HTTP/2 protocol also faced criticism for not supportingopportunistic encryption, a measure againstpassive monitoring similar to the STARTTLS mechanism that has long been available in other Internet protocols likeSMTP. Critics have stated that the HTTP/2 proposal goes in violation of IETF's ownRFC7258 "Pervasive Monitoring Is an Attack", which also has a status ofBest Current Practice 188.[54] RFC7258/BCP188 mandates that pervasive monitoring be considered as an attack, and protocols designed by IETF should take steps to protect against passive monitoring (for example, through the use of opportunistic encryption). A number of specifications for opportunistic encryption of HTTP/2 have been provided,[55][56][57] of which draft-nottingham-http2-encryption was adopted as an official work item of the working group, leading to the publication ofRFC8164 in May 2017.
Although the design of HTTP/2 effectively addresses the HTTP-transaction-levelhead-of-line blocking problem by allowing multiple concurrent HTTP transactions, all those transactions are multiplexed over a single TCP connection, meaning that any packet-level head-of-line blocking of the TCP stream simultaneously blocks all transactions being accessed via that connection. This head-of-line blocking in HTTP/2 is now widely regarded as a design flaw, and much of the effort behindQUIC andHTTP/3 has been devoted to reduce head-of-line blocking issues.[58][59]
Apache httpd 2.4.12 supports HTTP/2 via the module mod_h2,[60] although appropriate patches must be applied to the source code of the server in order for it to support that module. As of Apache 2.4.17 all patches are included in the main Apache source tree, although the module itself was renamed mod_http2.[61] Old versions of SPDY were supported via the module mod_spdy,[62] however the development of the mod_spdy module has stopped.[63]
PageCDN supports HTTP/2 out of the box and provides user-interface to setup HTTP/2 Server Push in CDN dashboard.[89]
CDN77 supports HTTP/2 using nginx(August 20, 2015).
Cloudflare supports HTTP/2 using nginx with SPDY as a fallback for browsers without support, whilst maintaining all security and performance services.[90] Cloudflare was the first major CDN to supportHTTP/2 Server Push.[91]
^abIlya Grigorik."Chapter 12: HTTP 2.0".High Performance Browser Networking. O'Reilly Media, Inc.HTTP/2 does not modify the application semantics of HTTP in any way
^Belshe, Mike; Thomson, Martin; Peon, Roberto (May 2015). Thomson, M. (ed.)."Hypertext Transfer Protocol Version 2 (HTTP/2)".tools.ietf.org.doi:10.17487/RFC7540. RetrievedNovember 17, 2017.HTTP/2 uses DATA frames to carry message payloads. The "chunked" transfer encoding defined in Section 4.1 of [RFC7230] MUST NOT be used in HTTP/2
^abIlya, Grigorik (2015).HTTP/2 : a new excerpt from high performance browser networking (May 2015, First ed.). Sebastopol, Calif.: O'Reilly Media. pp. 211–224.ISBN9781491932483.OCLC1039459460.
^Chris Bentzel; Bence Béky (February 9, 2015)."Hello HTTP/2, Goodbye SPDY".Chromium Blog.Update: To better align with Chrome's release cycle, SPDY and NPN support will be removed with the release of Chrome 51.
