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 (officially introduced in 2021), [3] a multiplexed transport protocol built on UDP. [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 September 2024, HTTP/3 is supported by 95% of all web browsers (though not enabled for all Safari users) [7] and 31% 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 ]

On 6 June 2022, IETF published HTTP/3 as a Proposed Standard in RFC   9114. [1]

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

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.

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

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.

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

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.

HTTP Strict Transport Security (HSTS) is a policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers should automatically interact with it using only HTTPS connections, which provide Transport Layer Security (TLS/SSL), unlike the insecure HTTP used alone. HSTS is an IETF standards track protocol and is specified in RFC 6797.

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

WebSocket is a computer communications protocol, providing a simultaneous two-way communication channel 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.

WebRTC is a free and open-source project providing web browsers and mobile applications with real-time communication (RTC) via application programming interfaces (APIs). It allows audio and video communication and streaming to work inside web pages by allowing direct peer-to-peer communication, eliminating the need to install plugins or download native apps.

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.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

QUIC is a general-purpose transport layer network protocol initially designed by Jim Roskind at Google. It was first implemented and deployed in 2012. It was publicly announced in 2013 as experimentation broadened, and was 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.

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.

Protocol ossification is the loss of flexibility, extensibility and evolvability of network protocols. This is largely due to middleboxes that are sensitive to the wire image of the protocol, and which can interrupt or interfere with messages that are valid but which the middlebox does not correctly recognise. This is a violation of the end-to-end principle. Secondary causes include inflexibility in endpoint implementations of protocols.

Version history for TLS/SSL support in web browsers tracks the implementation of Transport Layer Security protocol versions in major web browsers.

References

  1. 1 2 M. Bishop, ed. (June 2022). HTTP/3. Internet Engineering Task Force. doi: 10.17487/RFC9114 . ISSN   2070-1721. RFC 9114.Proposed Standard.
  2. ↑ V. Cerf; Y. Dalal; C. Sunshine (December 1974). SPECIFICATION OF INTERNET TRANSMISSION CONTROL PROGRAM. Network Working Group. doi: 10.17487/RFC0675 . RFC 675.Obsolete. Obsoleted by RFC  7805. NIC 2. INWG 72.
  3. ↑ J. Iyengar; M. Thomson, eds. (May 2021). QUIC: A UDP-Based Multiplexed and Secure Transport. Internet Engineering Task Force. doi: 10.17487/RFC9000 . ISSN   2070-1721. RFC 9000.Proposed Standard.
  4. ↑ "What is HTTP/3?". Cloudflare. Archived from the original on 4 July 2022. Retrieved 12 July 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. hdl: 11368/3025202 . 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 11 August 2024.
  8. ↑ "Usage of HTTP/3 for websites". World Wide Web Technology Surveys. W3Techs. Retrieved 11 August 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. 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.