Firefox nightly builds now support HTTP/3

В nightly builds Firefox, which will form the basis for the release of Firefox 72, scheduled for January 7, added HTTP/3 protocol support. By default, HTTP/3 is disabled and requires the “network.http.http3.enabled” option to be activated in about:config.

HTTP/3 support in Firefox is based on a project developed by Mozilla neqo, which provides a client and server implementation for the QUIC protocol. The component code for HTTP/3 and QUIC support is written in Rust.
From client software, experimental support for HTTP/3 is also already added in Chrome and curl, and for servers it is available in the form module for nginx and test server library based q (Realization of QUIC and HTTP/3 in Rust from Cloudflare). To test the operation of HTTP/3 clients launched several test sites, most of which do not open correctly in Firefox yet (HTTP/3 is at the stage draft specification and is not completely standardized).

Recall that HTTP/3 standardizes the use of the QUIC protocol as a transport for HTTP/2. Protocol HERE C (Quick UDP Internet Connections) has been developed by Google since 2013 as an alternative to TCP + TLS for the Web, solving problems with long setup and negotiation times for connections in TCP and eliminating delays in case of packet loss during data transfer. QUIC is an add-on to the UDP protocol that supports multiplexing of multiple connections and provides encryption methods equivalent to TLS/SSL.

All features QUIC:

• High security, similar to TLS (in fact, QUIC provides the ability to use TLS over UDP);
• Stream integrity control to prevent packet loss;
• The ability to instantly establish a connection (0-RTT, in about 75% of cases, data can be transmitted immediately after sending a connection setup packet) and ensure minimal delays between sending a request and receiving a response (RTT, Round Trip Time);
• Do not use the same sequence number when retransmitting a packet, which allows you to avoid ambiguity in determining the received packets and get rid of timeouts;
• Packet loss only affects the delivery of the stream associated with it and does not stop the delivery of data in streams transmitted in parallel over the current connection;
• Error correction tools that minimize delays due to retransmission of lost packets. Use of special error correction codes at the packet level to reduce situations that require retransmission of lost packet data.
• The boundaries of the cryptographic blocks are aligned with the boundaries of the QUIC packets, which reduces the impact of packet loss on the decoding of the contents of the following packets;
• No problems with blocking the TCP queue;
• Connection ID support to reduce reconnection time for mobile clients;
• Possibility to connect advanced mechanisms for connection overload control;
• Using bandwidth prediction techniques in each direction to ensure the optimal intensity of sending packets, preventing rolling into a state of congestion, in which there is a loss of packets;
• Perceptible growth performance and throughput compared to TCP. For video services such as YouTube, QUIC has been shown to reduce video rebuffering operations by 30%.

Source: opennet.ru