HTTP/3

Last updated
HTTP/3
International standard RFC   9114 [1] (HTTP/3 also uses the completed QUIC protocol described in RFC 9000 and related RFCs such as RFC 9001)
Developed by IETF
IntroducedJune 2022
Website https://httpwg.org/specs/rfc9114.html

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 (published in 1974), [2] HTTP/3 uses QUIC, a multiplexed transport protocol built on UDP. [3] On 6 June 2022, IETF published HTTP/3 as a Proposed Standard in RFC   9114. [4]

Contents

HTTP/3 uses similar semantics compared to earlier revisions of the protocol, including the same request methods, status codes, and message fields, but encodes them and maintains session state differently. However, partially due to the protocol's adoption of QUIC, HTTP/3 has lower latency and loads more quickly in real-world usage when compared with previous versions: in some cases over four times as fast than with HTTP/1.1 (which, for many websites, is the only HTTP version deployed). [5] [6]

As of April 2024, HTTP/3 is at least partially supported by 97% of all web browser installations and 98% of mobile web browser installations tracked by "Can I Use", a website that tracks and provides information on web technologies compatibility with different web browsers. [7] HTTP/3 is supported by 29% of the top 10 million websites. [8] It has been supported by Chromium (and derived projects including Google Chrome, Microsoft Edge, Samsung Internet, and Opera) [9] since April 2020 and by Mozilla Firefox since May 2021. [7] [10] Safari 14 implemented the protocol but it remains disabled by default. [11]

History

Protocol stack of HTTP/3 compared to HTTP/1.1 and HTTP/2 HTTP-1.1 vs. HTTP-2 vs. HTTP-3 Protocol Stack.svg
Protocol stack of HTTP/3 compared to HTTP/1.1 and HTTP/2

HTTP/3 originates from an Internet Draft adopted by the QUIC working group. The original proposal was named "HTTP/2 Semantics Using The QUIC Transport Protocol", [12] and later renamed "Hypertext Transfer Protocol (HTTP) over QUIC". [13]

On 28 October 2018 in a mailing list discussion, Mark Nottingham, Chair of the IETF HTTP and QUIC Working Groups, proposed renaming HTTP-over-QUIC to HTTP/3, to "clearly identify it as another binding of HTTP semantics to the wire protocol [...] so people understand its separation from QUIC". [14] Nottingham's proposal was accepted by fellow IETF members a few days later. The HTTP working group was chartered to assist the QUIC working group during the design of HTTP/3, then assume responsibility for maintenance after publication. [15]

Support for HTTP/3 was added to Chrome (Canary build) in September 2019 and then eventually reached stable builds, but was disabled by a feature flag. It was enabled by default in April 2020. [9] Firefox added support for HTTP/3 in November 2019 through a feature flag [7] [16] [17] and started enabling it by default in April 2021 in Firefox 88. [7] [10] Experimental support for HTTP/3 was added to Safari Technology Preview on April 8, 2020 [18] and was included with Safari 14 that ships with iOS 14 and macOS 11, [11] [19] but it's still disabled by default as of Safari 16, on both macOS and iOS.[ citation needed ]

Comparison with HTTP/1.1 and HTTP/2

HTTP semantics are consistent across versions: the same request methods, status codes, and message fields are typically applicable to all versions. The differences are in the mapping of these semantics to underlying transports. Both HTTP/1.1 and HTTP/2 use TCP as their transport. HTTP/3 uses QUIC, a transport layer network protocol which uses user space congestion control over the User Datagram Protocol (UDP). The switch to QUIC aims to fix a major problem of HTTP/2 called "head-of-line blocking": because the parallel nature of HTTP/2's multiplexing is not visible to TCP's loss recovery mechanisms, a lost or reordered packet causes all active transactions to experience a stall regardless of whether that transaction was impacted by the lost packet. Because QUIC provides native multiplexing, lost packets only impact the streams where data has been lost.

Proposed DNS resource records SVCB (service binding) and HTTPS would allow connecting without first receiving the Alt-Svc header via previous HTTP versions, therefore removing the 1 RTT of handshaking of TCP. [20] [21] There is client support for HTTPS resource records since Firefox 92, iOS 14, reported Safari 14 support, and Chromium supports it behind a flag. [22] [23] [24]

Implementations

Client

Browser support for HTTP/3
BrowserVersion implemented (disabled by default)Version shipped (enabled by default)Comment
Chrome Stable build (79)December 201987 [7] April 2020 [25] Earlier versions implemented other drafts of QUIC
Edge Stable build (79)December 201987April 2020Edge 79 was the first version based on Chromium
Firefox Stable build (72.0.1)January 202088 [10] April 2021 [26]
Safari Stable build (14.0)September 202016.4March 2023Apple is testing HTTP/3 support on some Safari users starting with Safari 16.4. [27]

Libraries

Open-source libraries that implement client or server logic for QUIC and HTTP/3 include [28]

Libraries implementing HTTP/3
NameClientServerProgramming languageCompanyRepository
lsquicYesYesC LiteSpeed https://github.com/litespeedtech/lsquic
nghttp3YesYesC https://github.com/ngtcp2/nghttp3
h2o NoYesC https://github.com/h2o/h2o
libcurl [29] [30] YesNoC https://github.com/curl/curl
MsQuic [31] YesYesC Microsoft https://github.com/microsoft/msquic
proxygenYesYesC++ Facebook https://github.com/facebook/proxygen#quic-and-http3
CronetYesYesC++ Google https://github.com/chromium/chromium/tree/main/net/quic
.NET [32] YesYesC# (using MsQuic) [33] Microsoft https://github.com/dotnet
quic-goYesYesGo https://github.com/quic-go/quic-go
http3YesYesHaskell https://github.com/kazu-yamamoto/http3
KwikYesYesJava https://github.com/ptrd/kwik
FlupkeYesYesJava https://bitbucket.org/pjtr/flupke
aioquicYesYesPython https://github.com/aiortc/aioquic
quicheYesYesRust Cloudflare https://github.com/cloudflare/quiche
neqoYesYesRust Mozilla https://github.com/mozilla/neqo
quinnYesYesRust https://github.com/quinn-rs/quinn
s2n-quicYesYesRust Amazon Web Services https://github.com/aws/s2n-quic

Server

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.

<span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

<span class="mw-page-title-main">Firefox</span> Free and open-source web browser by Mozilla

Mozilla Firefox, or simply Firefox, is a free and open-source web browser developed by the Mozilla Foundation and its subsidiary, the Mozilla Corporation. It uses the Gecko rendering engine to display web pages, which implements current and anticipated web standards. Firefox is available for Windows 10 or later versions, macOS, and Linux. Its unofficial ports are available for various Unix and Unix-like operating systems, including FreeBSD, OpenBSD, NetBSD, illumos, and Solaris Unix. It is also available for Android and iOS. However, as with all other iOS web browsers, the iOS version uses the WebKit layout engine instead of Gecko due to platform requirements. An optimized version is also available on the Amazon Fire TV as one of the two main browsers available with Amazon's Silk Browser.

In computing, the User-Agent header is an HTTP header intended to identify the user agent responsible for making a given HTTP request. Whereas the character sequence User-Agent comprises the name of the header itself, the header value that a given user agent uses to identify itself is colloquially known as its user agent string. The user agent for the operator of a computer used to access the Web has encoded within the rules that govern its behavior the knowledge of how to negotiate its half of a request-response transaction; the user agent thus plays the role of the client in a client–server system. Often considered useful in networks is the ability to identify and distinguish the software facilitating a network session. For this reason, the User-Agent HTTP header exists to identify the client software to the responding server.

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 6960 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.

This is a comparison of both historical and current web browsers based on developer, engine, platform(s), releases, license, and cost.

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

Datagram Transport Layer Security (DTLS) is a communications protocol providing security to datagram-based applications by allowing them to communicate in a way designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the stream-oriented Transport Layer Security (TLS) protocol and is intended to provide similar security guarantees. The DTLS protocol datagram preserves the semantics of the underlying transport—the application does not suffer from the delays associated with stream protocols, but because it uses UDP or SCTP, the application has to deal with packet reordering, loss of datagram and data larger than the size of a datagram network packet. Because DTLS uses UDP or SCTP rather than TCP, it avoids the "TCP meltdown problem", when being used to create a VPN tunnel.

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

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

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.

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 initial HTTP/2 specification was published as RFC 7540 on May 14, 2015.

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.

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.

Media Source Extensions (MSE) is a W3C specification that allows JavaScript to send byte streams to media codecs within web browsers that support HTML5 video and audio. Among other possible uses, this allows the implementation of client-side prefetching and buffering code for streaming media entirely in JavaScript. It is compatible with, but should not be confused with, the Encrypted Media Extensions (EME) specification, and neither requires the use of the other, although many EME implementations are only capable of decrypting media data provided via MSE.

DNS over HTTPS (DoH) is a protocol for performing remote Domain Name System (DNS) resolution via the HTTPS protocol. A goal of the method is to increase user privacy and security by preventing eavesdropping and manipulation of DNS data by man-in-the-middle attacks by using the HTTPS protocol to encrypt the data between the DoH client and the DoH-based DNS resolver. By March 2018, Google and the Mozilla Foundation had started testing versions of DNS over HTTPS. In February 2020, Firefox switched to DNS over HTTPS by default for users in the United States. In May 2020, Chrome switched to DNS over HTTPS by default.

References

  1. ↑ Bishop, Mike; Akamai. "RFC 9114: HTTP/3". rfc-editor. Retrieved 6 June 2022.
  2. ↑ Cerf, V.; Dalal, Y.; Sunshine, C. (December 1974). "Specification of Internet Transmission Control Program". IETF: RFC0675. doi: 10.17487/rfc0675 .
  3. ↑ "What is HTTP/3?". Cloudflare. Archived from the original on 4 July 2022. Retrieved 12 July 2022.
  4. ↑ "HTTP/3". 6 June 2022. Retrieved 6 June 2022.
  5. ↑ Perna, Gianluca; Trevisan, Martino; Giordano, Danilo; Drago, Idilio (1 April 2022). "A first look at HTTP/3 adoption and performance". Computer Communications. 187: 115–124. doi:10.1016/j.comcom.2022.02.005. ISSN   0140-3664. S2CID   246936473.
  6. ↑ "HTTP/3 is Fast". Request Metrics. Retrieved 1 July 2022.
  7. 1 2 3 4 5 ""HTTP/3" | Can I use... Support tables for HTML5, CSS3, etc". canIuse.com. Retrieved 24 April 2024.
  8. ↑ "Usage of HTTP/3 for websites". World Wide Web Technology Surveys. W3Techs. Retrieved 2 February 2024.
  9. 1 2 "Enabling QUIC in tip-of-tree". groups.google.com. Retrieved 8 April 2021.
  10. 1 2 3 Damjanovic, Dragana (16 April 2021). "QUIC and HTTP/3 Support now in Firefox Nightly and Beta". Mozilla Hacks – the Web developer blog. Retrieved 17 April 2021.
  11. 1 2 "Safari 14 Release Notes". developer.apple.com. Retrieved 4 December 2020.
  12. ↑ Shade, Robbie (8 July 2016). HTTP/2 Semantics Using The QUIC Transport Protocol. IETF. I-D draft-shade-quic-http2-mapping.
  13. ↑ Cimpanu, Catalin (12 November 2018). "HTTP-over-QUIC to be renamed HTTP/3 | ZDNet". ZDNet. Retrieved 12 November 2018.
  14. ↑ Nottingham, Mark (28 October 2018). "Identifying our deliverables". IETF Mail Archive.
  15. ↑ "Hypertext Transfer Protocol Charter". ietf.org. Retrieved 2 September 2020.
  16. ↑ Daniel, Stenberg. "Daniel Stenberg announces HTTP/3 support in Firefox Nightly". Twitter. Retrieved 5 November 2019.
  17. ↑ Cimpanu, Catalin (26 September 2019). "Cloudflare, Google Chrome, and Firefox add HTTP/3 support". ZDNet. Retrieved 27 September 2019.
  18. ↑ "Release Notes for Safari Technology Preview 104". webkit.org. 8 April 2020. Retrieved 7 August 2020.
  19. ↑ Ng, Gary (23 June 2020). "Apple's Safari Adds Support for HTTP3 in iOS 14 and macOS 11". iphoneincanada.ca. Retrieved 25 June 2021.
  20. ↑ "HTTPS RR". MDN . Mozilla . Retrieved 25 October 2022.
  21. ↑ Schwartz, Benjamin M.; Bishop, Mike; Nygren, Erik (12 June 2020). Service binding and parameter specification via the DNS. IETF. I-D draft-ietf-dnsop-svcb-https.
  22. ↑ "Firefox 92 for developers". Mozilla Corporation. 7 September 2021. Retrieved 25 October 2022.
  23. ↑ "Feature: HTTP->HTTPS redirect for HTTPS DNS records". Google Inc. Retrieved 25 October 2022.
  24. ↑ Patrick Mevzek (24 August 2021). "What's the use case of SVCB (type 65, service binding) RR". Stack Exchange Inc. Retrieved 25 October 2022.
  25. ↑ "Enabling QUIC in tip-of-tree". groups.google.com. Retrieved 9 April 2021.
  26. ↑ "Firefox Release Owners - MozillaWiki". wiki.mozilla.org. Retrieved 9 April 2021.
  27. ↑ Jen Simmons (4 April 2023). "HTTP/3 support shipped in Safari 14.0". GitHub. Retrieved 7 April 2023.
  28. ↑ "QUIC Implementations". GitHub. Retrieved 8 April 2021.
  29. ↑ "First HTTP/3 with curl". Daniel Stenberg. 5 August 2019. Retrieved 2 October 2019.
  30. ↑ "HTTP3 (and QUIC)". Daniel Stenberg. 23 August 2023. Retrieved 27 August 2023.
  31. ↑ "MsQuic is Open Source". 28 April 2020. Retrieved 28 April 2020.
  32. ↑ "HTTP/3 support in .NET 6". 17 September 2021. Retrieved 17 September 2021.
  33. ↑ "HTTP/3 support in .NET 6". .NET Blog. 17 September 2021. Retrieved 12 January 2022.
  34. ↑ "LiteSpeed Web Server Release Log - LiteSpeed Technologies". www.litespeedtech.com. Retrieved 12 February 2022. Enable HTTP/3 v1 by default.
  35. ↑ "Release 2.6.0 · caddyserver/caddy". Github. 22 September 2022. Retrieved 20 September 2022.
  36. ↑ "Introducing a Technology Preview of NGINX Support for QUIC and HTTP/3". NGINX. 10 June 2020. Retrieved 11 June 2020.
  37. ↑ "Binary Packages Now Available for the Preview NGINX QUIC+HTTP/3 Implementation". NGINX. 8 February 2023. Retrieved 30 March 2023.
  38. ↑ "Experiment with HTTP/3 using NGINX and quiche". The Cloudflare Blog. 17 October 2019. Retrieved 9 November 2019.
  39. ↑ Tratcher. "Use ASP.NET Core with HTTP/3 on IIS". docs.microsoft.com. Retrieved 29 April 2022.
  40. ↑ "Announcing HAProxy 2.6". HAProxy Blog. 31 May 2022.
  41. ↑ "QUIC Implementation in HAProxy". HAProxyConf video presentation.

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.