HTTP/2

Last updated

HTTP/2
International standard RFC   9113
Developed by IETF
IntroducedMay 14, 2015;8 years ago (2015-05-14)
Website https://http2.github.io/

HTTP/2 (originally named HTTP/2.0) 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. [1] [2] HTTP/2 was developed by the HTTP Working Group (also called httpbis, where "bis" means "twice") of the Internet Engineering Task Force (IETF). [3] [4] [5] 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, [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). [8] [9] The initial HTTP/2 specification was published as RFC   7540 on May 14, 2015. [10]

Contents

The standardization effort was supported by Chrome, Opera, Firefox, [11] Internet Explorer 11, Safari, Amazon Silk, and Edge browsers. [12] Most major browsers had added HTTP/2 support by the end of 2015. [13] About 97% of web browsers used have the capability (and 100% of "tracked desktop" web browsers). [13] As of July 2023, 36% (after topping out at just over 50%) of the top 10 million websites support HTTP/2. [14]

Its successor is HTTP/3, a major revision that builds on the concepts established by HTTP/2. [2] [15] [13] [16]

Goals

The working group charter mentions several goals and issues of concern: [4]

Differences from HTTP/1.1

The proposed changes do not require any changes to how existing web applications work, but new applications can take advantage of new features for increased speed. [17] HTTP/2 leaves all of HTTP/1.1's high-level semantics, such as methods, status codes, header fields, and URIs, the same. What is new is how the data is framed and transported between the client and the server. [17]

Websites that are efficient minimize the number of requests required to render an entire page by minifying (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. [18]

Additional performance improvements in the first draft of HTTP/2 (which was a copy of SPDY) come from multiplexing of requests and responses to avoid some of the head-of-line blocking problem in HTTP 1 (even when HTTP pipelining is used), header compression, and prioritization of requests. [19] 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. [20] HTTP/2 no longer supports HTTP/1.1's chunked transfer encoding mechanism, as it provides its own, more efficient, mechanisms for data streaming. [21]

History

Genesis in and later differences from SPDY

SPDY (pronounced like "speedy") was a previous HTTP-replacement protocol developed by a research project spearheaded by Google. [22] 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". [23]

The HTTP Working Group considered Google's SPDY protocol, Microsoft's HTTP Speed+Mobility proposal (SPDY based), [22] and Network-Friendly HTTP Upgrade. [24] In July 2012, Facebook provided feedback on each of the proposals and recommended HTTP/2 be based on SPDY. [25] The initial draft of HTTP/2 was published in November 2012 and was based on a straight copy of SPDY. [26]

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". [23] [27] SPDY showed evident improvement over HTTP, with a new page load speedup ranging from 11% to 47%. [28]

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 fixed Huffman code-based header compression algorithm, instead of SPDY's dynamic stream-based compression. This helps to reduce the potential for compression oracle attacks on the protocol, such as the CRIME attack. [27]

On February 9, 2015, Google announced plans to remove support for SPDY in Chrome in favor of support for HTTP/2. [29] This took effect starting with Chrome 51. [30] [31]

Development milestones

DateMilestone [4]
December 20, 2007 [32] [33] First HTTP/1.1 Revision Internet Draft
January 23, 2008 [34] First HTTP Security Properties Internet Draft
Early 2012 [35] Call for Proposals for HTTP 2.0
October 14 – November 25, 2012 [36] [37] Working Group Last Call for HTTP/1.1 Revision
November 28, 2012 [38] [39] First WG draft of HTTP 2.0, based upon draft-mbelshe-httpbis-spdy-00
Held/EliminatedWorking Group Last Call for HTTP Security Properties
September 2013 [40] [41] Submit HTTP/1.1 Revision to IESG for consideration as a Proposed Standard
February 12, 2014 [42] IESG approved HTTP/1.1 Revision to publish as a Proposed Standard
June 6, 2014 [32] [43] Publish HTTP/1.1 Revision as RFC   7230 , 7231 , 7232 , 7233 , 7234 , 7235
August 1, 2014 – September 1, 2014 [7] [44] Working Group Last call for HTTP/2
December 16, 2014 [6] Submit HTTP/2 to IESG for consideration as a Proposed Standard
December 31, 2014 – January 14, 2015 [45] IETF Last Call for HTTP/2
January 22, 2015 [46] IESG telechat to review HTTP/2 as Proposed Standard
February 17, 2015 [8] IESG approved HTTP/2 to publish as Proposed Standard
May 14, 2015 [47] Publish HTTP/2 as RFC   7540
February 2020 RFC   8740: HTTP/2 with TLS 1.3
June 2022 RFC   9113: Further refinements
April 2024DOS issues with CONTINUATION frames https://kb.cert.org/vuls/id/421644

Encryption

HTTP/2 is defined both for HTTP URIs (i.e. without TLS encryption, a configuration which is abbreviated in h2c) and for HTTPS URIs (over TLS using ALPN extension [48] where TLS 1.2 or newer is required, a configuration which is abbreviated in h2).

Although the standard itself does not require usage of encryption, [49] all major client implementations (Firefox, [50] Chrome, Safari, Opera, IE, Edge) have stated that they will only support HTTP/2 over TLS, which makes encryption de facto mandatory. [51]

Criticisms

Development process

The FreeBSD and Varnish developer Poul-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 the protocol layering principle, for example by duplicating flow control that belongs in the transport layer (TCP). He also suggested that the new protocol should have removed HTTP Cookies, introducing a breaking change. [52]

Encryption

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. [53] Poul-Henning Kamp has criticized the IETF for hastily standardizing Google's SPDY prototype as HTTP/2 due to political considerations. [52] [54] [55] 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 – a Cisco 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. [56] In the end the Working Group did not reach consensus over the mandatory encryption, [49] although most client implementations require it, which makes encryption a de facto requirement.

The HTTP/2 protocol also faced criticism for not supporting opportunistic encryption, a measure against passive monitoring similar to the STARTTLS mechanism that has long been available in other Internet protocols like SMTP. Critics have stated that the HTTP/2 proposal goes in violation of IETF's own RFC   7258 "Pervasive Monitoring Is an Attack", which also has a status of Best Current Practice 188. [57] RFC7258/BCP188 mandates that passive 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, [58] [59] [60] of which draft-nottingham-http2-encryption was adopted as an official work item of the working group, leading to the publication of RFC   8164 in May 2017.

TCP head-of-line blocking

Although the design of HTTP/2 effectively addresses the HTTP-transaction-level head-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 behind QUIC and HTTP/3 has been devoted to reduce head-of-line blocking issues. [61] [62]

Server-side support

Server software

The following web servers support HTTP/2:

Content delivery networks

Implementations

See also

Related Research Articles

<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.

The File Transfer Protocol (FTP) is a standard communication protocol used for the transfer of computer files from a server to a client on a computer network. FTP is built on a client–server model architecture using separate control and data connections between the client and the server. FTP users may authenticate themselves with a plain-text sign-in protocol, normally in the form of a username and password, but can connect anonymously if the server is configured to allow it. For secure transmission that protects the username and password, and encrypts the content, FTP is often secured with SSL/TLS (FTPS) or replaced with SSH File Transfer Protocol (SFTP).

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.

<span class="mw-page-title-main">HTTP compression</span> Capability that can be built into web servers and web clients

HTTP compression is a capability that can be built into web servers and web clients to improve transfer speed and bandwidth utilization.

<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.

Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. The extension allows a server to present one of multiple possible certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites to be served by the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. This also allows a proxy to forward client traffic to the right server during TLS/SSL handshake. The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested. The SNI extension was specified in 2003 in RFC 3546

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.

HTTP Speed+Mobility was an experimental open-specification communication protocol developed primarily at Microsoft for transporting web content. HTTP Speed+Mobility was similar to HTTP, with particular goals to reduce web page load latency and improve web security. As a revision of Google's SPDY protocol, Microsoft's HTTP Speed+Mobility protocol achieved reduced latency through SPDY's use of compression, multiplexing, and prioritization.

Application-Layer Protocol Negotiation (ALPN) is a Transport Layer Security (TLS) extension that allows the application layer to negotiate which protocol should be performed over a secure connection in a manner that avoids additional round trips and which is independent of the application-layer protocols. It is used to establish HTTP/2 connections without additional round trips.

In computer networking, TCP Fast Open (TFO) is an extension to speed up the opening of successive Transmission Control Protocol (TCP) connections between two endpoints. It works by using a TFO cookie, which is a cryptographic cookie stored on the client and set upon the initial connection with the server. When the client later reconnects, it sends the initial SYN packet along with the TFO cookie data to authenticate itself. If successful, the server may start sending data to the client even before the reception of the final ACK packet of the three-way handshake, thus skipping a round-trip delay and lowering the latency in the start of data transmission.

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/2 Server Push is an optional 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. 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.

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. ↑ Bright, Peter (February 18, 2015). "HTTP/2 finished, coming to browsers within weeks". Ars Technica. Archived from the original on March 30, 2019.
  2. 1 2 Cimpanu, Catalin (November 12, 2018). "HTTP-over-QUIC to be renamed HTTP/3". ZDNet. Retrieved November 19, 2018.
  3. ↑ Thomson, M.; Belshe, M.; Peon, R. (November 29, 2014). "Hypertext Transfer Protocol version 2: draft-ietf-httpbis-http2-16". Ietf Datatracker. HTTPbis Working Group. Retrieved February 11, 2015.
  4. 1 2 3 "HTTP (httpbis)". Internet Engineering Task Force Datatracker. Archived from the original on January 6, 2024.
  5. ↑ "IETF HTTP Working Group". httpwg.org. Retrieved December 15, 2019.
  6. 1 2 "History for draft-ietf-httpbis-http2-16". IETF. Retrieved January 3, 2015. 2014-12-16 IESG state changed to Publication Requested
  7. 1 2 Raymor, Brian (August 6, 2014). "Wait for it – HTTP/2 begins Working Group Last Call!". Microsoft Open Technologies. Archived from the original on October 6, 2014. Retrieved October 17, 2018.
  8. 1 2 The IESG (February 17, 2015). "Protocol Action: 'Hypertext Transfer Protocol version 2' to Proposed Standard (draft-ietf-httpbis-http2-17.txt)". httpbis (Mailing list). Retrieved February 18, 2015.
  9. ↑ Mark Nottingham (February 18, 2015). "HTTP/2 Approved". ietf.org. Internet Engineering Task Force . Retrieved March 8, 2015.
  10. ↑ Belshe, M.; Peon, R.; Thomson, M. (May 2015). Thomson, M (ed.). "RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)". IETF. doi: 10.17487/RFC7540 . Retrieved May 14, 2015.{{cite journal}}: Cite journal requires |journal= (help)
  11. ↑ "See what's new in Firefox!". www.mozilla.org. Mozilla Foundation. February 2015.
  12. ↑ "Can the rise of SPDY threaten HTTP?". blog.restlet.com. Restlet, Inc. October 2011. Archived from the original on January 6, 2014. Retrieved July 23, 2012.
  13. 1 2 3 ""HTTP/2" | Can I use... Support tables for HTML5, CSS3, etc". canIuse.com. Retrieved April 3, 2023.
  14. ↑ "Usage of HTTP/2 for websites". World Wide Web Technology Surveys. W3Techs. Retrieved July 10, 2023.
  15. ↑ Bishop, Mike (July 9, 2019). "Hypertext Transfer Protocol Version 3 (HTTP/3)". Ietf Datatracker. Retrieved July 31, 2019.
  16. ↑ Cimpanu, Catalin (26 September 2019). "Cloudflare, Google Chrome, and Firefox add HTTP/3 support". ZDNet. Retrieved 27 September 2019.
  17. 1 2 Ilya 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
  18. ↑ Pratt, Michael. "Apiux". apiux.com. Retrieved March 19, 2014.
  19. ↑ Dio Synodinos (November 2012). "HTTP 2.0 First Draft Published". InfoQ.com. C4Media Inc.
  20. ↑ Javier Garza (October 2017). "How does HTTP/2 solve the Head of Line blocking (HOL) issue".
  21. ↑ 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 . Retrieved November 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
  22. 1 2 Sebastian Anthony (March 28, 2012). "S&M vs. SPDY: Microsoft and Google battle over the future of HTTP 2.0". ExtremeTech.
  23. 1 2 Grigorik, Ilya. "Life beyond HTTP 1.1: Google's SPDY".
  24. ↑ Willy Tarreau; Amos Jeffries; Adrien de Croy; Poul-Henning Kamp (March 29, 2012). "Proposal for a Network-Friendly HTTP Upgrade". Network Working Group. Internet Engineering Task Force.
  25. ↑ Doug Beaver (July 15, 2012). "HTTP2 Expression of Interest" (mailing list). W3C.
  26. ↑ Dio Synodinos (November 30, 2012). "HTTP/2 First Draft Published". InfoQ.
  27. 1 2 Ilya, Grigorik (2015). HTTP/2 : a new excerpt from high performance browser networking (May 2015, First ed.). Sebastopol, Calif.: O'Reilly Media. pp. 211–224. ISBN   9781491932483. OCLC   1039459460.
  28. ↑ "SPDY: An experimental protocol for a faster web". The Chromium Projects.
  29. ↑ 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.
  30. ↑ "API Deprecations and Removals in Chrome 51". TL;DR: Support for HTTP/2 is widespread enough that SPDY/3.1 support can be dropped.
  31. ↑ Shadrin, Nick (June 7, 2016). "Supporting HTTP/2 for Google Chrome Users | NGINX". NGINX. Retrieved July 10, 2017.
  32. 1 2 Nottingham, Mark (June 7, 2014). "RFC2616 is Dead" . Retrieved September 20, 2014.
  33. ↑ "HTTP/1.1, part 1: URIs, Connections, and Message Parsing: draft-ietf-httpbis-p1-messaging-00". December 20, 2007. Retrieved September 20, 2014.
  34. ↑ "Security Requirements for HTTP: draft-ietf-httpbis-security-properties-00.txt". January 23, 2008. Retrieved September 20, 2014.
  35. ↑ Nottingham, Mark (January 24, 2012). "Rechartering HTTPbis" . Retrieved September 20, 2014.
  36. ↑ Nottingham, Mark (October 14, 2012). "Working Group Last Call for HTTP/1.1 p1 and p2" . Retrieved September 20, 2014.
  37. ↑ Nottingham, Mark (October 23, 2012). "Second Working Group Last Call for HTTP/1.1 p4 to p7" . Retrieved September 20, 2014.
  38. ↑ "SPDY Protocol: draft-ietf-httpbis-http2-00". HTTPbis Working Group. November 28, 2012. Retrieved September 20, 2014.
  39. ↑ Nottingham, Mark (November 30, 2012). "First draft of HTTP/2" . Retrieved September 20, 2014.
  40. ↑ Fielding, Roy T.; Reschke, Julian (June 6, 2014). "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing". Archived from the original on August 13, 2014. Retrieved September 20, 2014.
  41. ↑ "Last Call: <draft-ietf-httpbis-p1-messaging-24.txt> (Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing) to Proposed Standard". The IESG. October 21, 2013. Retrieved September 20, 2014.
  42. ↑ "Protocol Action: 'Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing' to Proposed Standard (draft-ietf-httpbis-p1-messaging-26.txt)". ietf-announce (Mailing list). The IESG. February 12, 2014. Retrieved January 18, 2015.
  43. ↑ The RFC Editor Team (June 6, 2014). "RFC 7230 on Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing". ietf-announce (Mailing list). Retrieved January 18, 2015.{{cite mailing list}}: |last= has generic name (help)
  44. ↑ Nottingham, Mark (August 1, 2014). "Working Group Last Call: draft-ietf-httpbis-http2-14 and draft-ietf-httpbis-header-compression-09". HTTP Working Group. Retrieved September 7, 2014.
  45. ↑ "Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard from The IESG on 2014-12-31". Internet Engineering Task Force. 2014. Retrieved January 1, 2015.
  46. ↑ "IESG Agenda: 2015-01-22". IETF. Archived from the original on January 15, 2015. Retrieved January 15, 2015.
  47. ↑ The RFC Editor Team (May 14, 2015). "RFC 7540 on Hypertext Transfer Protocol Version 2 (HTTP/2)". ietf-announce (Mailing list).{{cite mailing list}}: |author= has generic name (help)
  48. ↑ Friedl, S.; Popov, A.; Langley, A.; Stephan, E. (July 2014). "RFC 7301 - Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension". IETF. doi: 10.17487/RFC7301 .{{cite journal}}: Cite journal requires |journal= (help)
  49. 1 2 "HTTP/2 Frequently Asked Questions". IETF HTTP Working Group. Retrieved September 8, 2014.
  50. ↑ "Networking/http2". MozillaWiki. Retrieved September 7, 2014.
  51. ↑ "HTTP/2 Implementation Status". mnot’s blog.
  52. 1 2 Kamp, Poul-Henning (January 6, 2015). "HTTP/2.0 – The IETF is Phoning It In (Bad protocol, bad politics)". ACM Queue.{{cite journal}}: Cite journal requires |journal= (help)
  53. ↑ Grigorik, Ilya. "Is TLS Fast Yet?" . Retrieved December 30, 2015.
  54. ↑ Kamp, P. H. (2015). "Http/2.0". Communications of the ACM. 58 (3): 40. doi:10.1145/2717515. S2CID   20337779.
  55. ↑ Kamp, Poul-Henning (January 7, 2015). "Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard". ietf-http-wg@w3.org (Mailing list). Retrieved January 12, 2015.
  56. ↑ Lear, Eliot (August 25, 2013). "Mandatory encryption *is* theater". ietf-http-wg@w3.org (Mailing list). Retrieved January 26, 2015.
  57. ↑ Murenin, Constantine A. (January 9, 2015). "Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard". ietf-http-wg@w3.org (Mailing list). Retrieved January 12, 2015.
  58. ↑ Paul Hoffman. "Minimal Unauthenticated Encryption (MUE) for HTTP-2: draft-hoffman-httpbis-minimal-unauth-enc-01". Internet Engineering Task Force.
  59. ↑ Mark Nottingham; Martin Thomson. "Opportunistic Encryption for HTTP URIs: draft-nottingham-http2-encryption-03". Internet Engineering Task Force.
  60. ↑ Mark Nottingham; Martin Thomson. "Opportunistic Security for HTTP: draft-ietf-httpbis-http2-encryption-01". Ietf Datatracker. Internet Engineering Task Force.
  61. ↑ Huston, Geoff (March 4, 2019). "A Quick Look at QUIC". www.circleid.com. Retrieved August 2, 2019.
  62. ↑ Gal, Shauli (June 22, 2017). "The Full Picture on HTTP/2 and HOL Blocking". Medium. Retrieved August 3, 2019.
  63. ↑ "http/2 module for apache httpd" . Retrieved July 28, 2015.
  64. ↑ "Apache 2.4.17 release changelog" . Retrieved August 22, 2017.
  65. ↑ Matthew Steele (June 19, 2014). "mod_spdy is now an Apache project". Google Developers Blog.
  66. ↑ "Log of /httpd/mod_spdy". svn.apache.org. Retrieved February 3, 2017.
  67. ↑ "Apache Tomcat Migration" . Retrieved July 29, 2016.
  68. ↑ "Apache Traffic Server Downloads". trafficserver.apache.org. September 21, 2015.
  69. ↑ Server, Caddy Web (March 23, 2016). "Caddy 2 - The Ultimate Server with Automatic HTTPS". caddyserver.com. Retrieved August 8, 2020.
  70. ↑ "Charles 4 has HTTP/2". Public Object. August 2, 2016. Retrieved October 12, 2020.
  71. ↑ "3 Simple Steps to Bring HTTP/2 Performance to Legacy Web Applications". September 22, 2015.
  72. ↑ "Sucuri += HTTP/2 — Announcing HTTP/2 Support". Sucuri. November 27, 2015. Retrieved December 5, 2015.
  73. ↑ Robert Haynes. "Goodbye SPDY, Hello HTTP/2". F5 Networks. Retrieved September 18, 2015.
  74. ↑ Risov Chakrabortty (July 5, 2016). "New features, capabilities added to Barracuda Web Application Firewall". Barracuda Networks.
  75. ↑ "H2O - the optimized HTTP/2 server". h2o.examp1e.net.
  76. ↑ "What's New in HAProxy 1.8". haproxy.com. November 2017. Retrieved February 9, 2018.
  77. ↑ "Jetty change log". Eclipse Foundation. May 28, 2015. Retrieved May 28, 2015.
  78. ↑ "Feature #2813: Support for HTTP/2 protocol", Lighttpd
  79. ↑ "LSWS 5.0 Is Out – Support for HTTP/2, ESI, LiteMage Cache". April 17, 2015.
  80. ↑ Rob Trace; David Walp (October 8, 2014). "HTTP/2: The Long-Awaited Sequel". MSDN IEBlog. Microsoft Corporation.
  81. ↑ "Netty.news: Netty 4.1.0.Final released". netty.io. Retrieved June 1, 2016.
  82. ↑ "nginx changelog". www.nginx.com. September 22, 2015.
  83. ↑ "Changes with nginx 1.14.2". nginx.org. December 4, 2018. Retrieved September 27, 2019.
  84. ↑ Foundation, Node js (November 20, 2018). "Node v8.13.0 (LTS)". Node.js. Retrieved June 5, 2019.
  85. ↑ "Node http2". www.github.com. July 26, 2016.
  86. ↑ "Node v8.4.0 (Current)". nodejs.org. August 15, 2017.
  87. ↑ "ASP.NET Core 2.2.0-preview1: HTTP/2 in Kestrel" . Retrieved April 6, 2021.
  88. ↑ "OpenLiteSpeed 1.4.5 change log". LiteSpeed Technologies, Inc. February 26, 2015. Retrieved February 26, 2015.
  89. ↑ "Pulse Virtual Traffic Manager". August 22, 2017.
  90. ↑ "Radware Combines an Integrated HTTP/2 Gateway with its Leading Fastview Technology to Provide Web Server Platforms Increased Acceleration". July 20, 2015.
  91. ↑ "www.shimmercat.com". March 23, 2016.
  92. ↑ "Why PageCDN, and what problem does it solve?". PageCDN. Retrieved January 11, 2020.
  93. ↑ "HTTP/2 is here! Goodbye SPDY? Not quite yet". CloudFlare. Retrieved December 5, 2015.
  94. ↑ Krasnov, Vlad (April 28, 2016). "Announcing Support for HTTP/2 Server Push". CloudFlare. Retrieved May 18, 2016.
  95. ↑ "Amazon CloudFront now supports HTTP/2". Amazon Web Services, Inc. Retrieved September 8, 2016.
  96. ↑ "Announcing Limited Availability for HTTP/2". June 30, 2016. Retrieved August 22, 2017.
  97. ↑ "HTTP/2 is here: What You Need to Know" . Retrieved November 1, 2015.
  98. ↑ "HTTP/2 more at risk to cyber attacks?". Information Age. August 3, 2016. Retrieved February 4, 2019.
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.