Mozilla has announced that it will start phasing in HTTP/3 and QUIC protocols with the April 88 release of Firefox 19 (originally scheduled for April 20, but according to the schedule, it has been pushed back by one day). Initially, HTTP/3 support will only be enabled for a small percentage of users and, unless there are unforeseen issues, will be rolled out to everyone by the end of May. In nightly builds and betas, HTTP/3 was enabled by default at the end of March.
Recall that Firefox's implementation of HTTP/3 is based on Mozilla's neqo project, which provides a client and server implementation for the QUIC protocol. The component code for HTTP/3 and QUIC support is written in Rust. To control whether HTTP/3 is enabled, about:config provides the "network.http.http3.enabled" option. From client software, experimental HTTP/3 support has also been added to Chrome and curl, and for servers it is available in nginx, as well as in the form of an nginx module and a test server from Cloudflare. On the site side, HTTP/3 support is already provided on Google and Facebook servers.
The HTTP/3 protocol is still in the draft specification stage and has not been definitively standardized by the IETF. Using HTTP/3 requires client and server side support for the same version of the QUIC and HTTP/3 draft standard, which is specified in the Alt-Svc header (Firefox supports draft specs 27 through 32).
HTTP/3 defines the use of the QUIC protocol as a transport for HTTP/2. The QUIC protocol (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. During the development of the IETF standard, changes were made to the protocol, which led to the emergence of two parallel existing branches, one for HTTP / 3, and the second supported by Google (Chrome supports both).
Main features of 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);
- Using a different 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;
- Noticeable performance and throughput gains over TCP. For video services such as YouTube, QUIC has been shown to reduce video rebuffering operations by 30%.
Source: opennet.ru