To experimental builds support for the HTTP/3 protocol, which implements an add-on to ensure HTTP operation over the QUIC protocol. The QUIC protocol itself was added to the browser five years ago and has since been used to optimize work with Google services. At the same time, Google's version of QUIC used in Chrome differed in some details from the version from IETF, but the implementations are now in sync.
HTTP/3 standardizes the use of QUIC as a transport for HTTP/2. To enable HTTP/3 and the QUIC option from IETF specifications require Chrome to be launched with options "--enable-quic --quic-version=h3-23", after which when opening a test site in Network Inspection mode, the developer tools will show HTTP/3 activity as "http/2+quic/99".
Recall that the 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. The protocol in question is already integrated into the Google server infrastructure, is part of Chrome, for inclusion in Firefox and is actively used to service client requests on Google servers.
All 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.
- Cryptographic block boundaries are aligned with QUIC packet boundaries, 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 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