Support for HTTP/3 has appeared in Firefox nightlies

In nightly builds Firefox, which will form the basis of the Firefox 72 release scheduled for January 7, has added supports the HTTP/3 protocol. By default, HTTP/3 is disabled and requires activation of the option 'network.http.http3.enabled' in about:config.

HTTP/3 support in Firefox is based on a project developed by Mozilla neqo, which provides an implementation of the client and server for the QUIC protocol. The code for the components supporting HTTP/3 and QUIC is written in Rust.
Experimental support for HTTP/3 is also already available in has added Chrome and curl, and for servers, it is available in the form of a module for nginx and a test server based on the library quiche (implementation of QUIC and HTTP/3 written in Rust by Cloudflare). To test HTTP/3 clients, several test websites have been launched, most of which do not yet open correctly in Firefox (HTTP/3 is in the draft specification and is not yet standardized). In the nightly builds of Firefox, which will form the basis of the Firefox 72 release scheduled for January 7.

It should be noted that HTTP/3 standardizes the use of the QUIC protocol as a transport for HTTP/2. The protocol QUIC (Quick UDP Internet Connections) 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 when packet loss occurs during data transfer. QUIC is an extension of the UDP protocol, supporting multiplexing of multiple connections and providing encryption methods equivalent to TLS/SSL.

Key Features 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);
• Not reusing the same sequence number for retransmitted packets, which helps avoid ambiguity in determining received packets and eliminates 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;
• Significant increase in performance and throughput compared to TCP. For video services like YouTube, the application of QUIC has shown a 30% reduction in rebuffering events during video playback.

Source: opennet.ru