In the nightly builds of Firefox, as well as in the beta version, support for the HTTP/3 protocol is enabled by default. In the stable branch, enabling HTTP/3 is scheduled for release in Firefox 88, planned for April 20.
HTTP/3 support in Firefox is based on the neqo project developed by Mozilla, which provides the implementation of the client and server for the QUIC protocol. The code components for supporting HTTP/3 and QUIC are written in Rust. To manage the enabling of HTTP/3, the option 'network.http.http3.enabled' is available in about:config. Experimental support for HTTP/3 has also been added to Chrome and curl, while servers is available in nginx, both as an nginx module and a test server from Cloudflare. Several test sites have been launched to verify the operation of HTTP/3 clients.
The HTTP/3 protocol is still in draft specification and has not yet been standardized by the IETF. HTTP/3 defines the use of the QUIC protocol as the transport for HTTP/2. The QUIC (Quick UDP Internet Connections) protocol has been developed by Google since 2013 as an alternative to the TCP+TLS stack for the web, addressing issues with long connection setup and negotiation times in TCP, and eliminating delays due to packet loss during data transmission. QUIC is an overlay over the UDP protocol that supports multiplexing multiple connections and provides encryption methods equivalent to TLS/SSL. During the development of the IETF standard, changes were made to the protocol, leading to the emergence of two parallel branches, one for HTTP/3 and the other supported by Google (Chrome supports both variants).
Key features of QUIC:
- High security, similar to TLS (essentially QUIC provides the possibility of using TLS over UDP);
- Stream integrity control that prevents packet loss;
- The ability to establish a connection instantly (0-RTT, allowing data to be sent immediately after sending the connection establishment packet in about 75% of cases) and ensure minimal delays between sending a request and receiving a response (RTT, Round Trip Time);
- Using a different sequence number when retransmitting a packet, which helps eliminate ambiguity in identifying received packets and avoids timeouts;
- Packet loss only affects the delivery of the associated stream and does not halt the delivery of data in parallel streams sent over the current connection;
- Error correction mechanisms that minimize delays caused by retransmitting lost packets. Utilizing special error correction codes at the packet level to reduce situations requiring the retransmission of lost packet data.
- The boundaries of cryptographic blocks are aligned with the boundaries of QUIC packets, reducing the impact of packet loss on the decoding of subsequent packet contents;
- No queue blocking issues as with TCP;
- Support for connection identifiers that reduce the time needed to establish a reconnection for mobile clients;
- The possibility of incorporating advanced congestion control mechanisms;
- The use of bandwidth prediction techniques in each direction to ensure optimal packet transmission intensity, preventing a fall into a state of congestion where packet loss occurs;
- A noticeable increase in performance and throughput compared to TCP. For video services like YouTube, the application of QUIC has shown a 30% reduction in rebuffering operations while watching videos.
Source: opennet.ru
