HTTP up to version 2 relies on the Transmission Control Protocol (TCP) as the transport protocol. TCP acknowledges receipt of each data packet. As a result, in the event of packet loss, all other packets have to wait for the lost one to be retransmitted (head-of-line blocking).
Google has been working on an alternative since 2012 under the name QUIC, which was adopted by the IETF and standardized in 2021. QUIC is a transport protocol that builds on the connectionless UDP and provides missing properties such as reliability and connection-oriented communication. Connections are encrypted, for which QUIC uses TLS version 1.3. QUIC supports multiplexing of multiple data streams, bypassing head-of-line blocking. If a packet is lost at QUIC, it will only block the streams that were included in the packet. QUIC’s connection negotiation is optimized to reduce latency to transmit the actual payload.
In November 2018, the IETF decided that HTTP over QUIC should be called HTTP/3. In June 2022, HTTP/3 was standardized as RFC 9114.
---
Even with HTTP/3, data streams are processed separately. If a packet is lost in transit, it no longer affects all data streams, as is the case with HTTP/2. With HTTP/3, the affected stream will wait for the missing packet to arrive. HTTP/3 is generally encrypted and promises significant speed advantages over HTTP/2 with TLS.
As of mid-2019, Google Chrome Canary was the first browser available to integrate experimental QUIC and HTTP/3 support. cURL soon followed suit. The pre-release versions of Firefox (nightly and beta) automatically attempt to use HTTP/3 when offered by the web server since April 2021. Web servers can indicate support by using the Alt-Svc response header or by announcing HTTP/3 support with an HTTPS DNS record.
Tagged With toward49j