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]
| 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 |
| Introduced | June 2022 |
| Website | https://httpwg.org/specs/rfc9114.html |
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
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 | Version implemented (disabled by default) | Version shipped (enabled by default) | Comment | ||
|---|---|---|---|---|---|
| Chrome | Stable build (79) | December 2019 | 87[7] | April 2020[25] | Earlier versions implemented other drafts of QUIC |
| Edge | Stable build (79) | December 2019 | 87 | April 2020 | Edge 79 was the first version based on Chromium |
| Firefox | Stable build (72.0.1) | January 2020 | 88[10] | April 2021[26] | |
| Safari | Stable build (14.0) | September 2020 | 16.4 | March 2023 | Apple 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]
Server
- On 7 June 2021, LiteSpeed Web Server (and OpenLiteSpeed) 6.0.2 was released and became the first version to enable HTTP/3 by default.[34]
- Caddy web server v2.6.0 (released 20 September 2022) has HTTP/3 enabled by default.[35]
- Nginx supports HTTP/3 since 1.25.0 (released 23 May 2023). A technology preview of nginx with HTTP/3 support was released in June 2020.[36] Binary packages of nginx with HTTP/3 support have been released in February 2023.[37]
- Cloudflare distributes a patch for nginx that integrates the quiche HTTP/3 library into it.[38]
- Microsoft IIS support for HTTP/3 is enabled natively with Windows Server 2022/Windows 11.[39]
- HAProxy supports HTTP/3 over QUIC since version 2.6 released on 31 May 2022.[40][41]
See also
- Fast and Secure Protocol – Terminal command scheme used to transfer data
