In experimental builds support for the HTTP/3 protocol, which implements an overlay to enable HTTP to work over the QUIC protocol. The QUIC protocol was introduced in the browser five years ago and has since been used to optimize interactions with Google services. The version of QUIC used in Chrome differed in some ways from the version from IETF, but now the implementations are synchronized.
HTTP/3 standardizes the use of QUIC as the transport for HTTP/2. To enable HTTP/3 and the QUIC variant from of IETF specifications, Chrome needs to be started with the options "—enable-quic —quic-version=h3-23", after which, when opening the test site in the network inspection mode of the Developer Tools, activity in HTTP/3 will be displayed as "http/2+quic/99".
Let’s recall that the protocol (Quick UDP Internet Connections) has been developed by Google since 2013 as an alternative to the TCP+TLS combination for the web, addressing issues with high connection setup and negotiation times in TCP and eliminating delays caused by 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. The protocol in question is already integrated into Google’s server infrastructure, is part of Chrome, is being enabled in Firefox, and is actively used to service client requests on Google servers.
Key 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.
- Cryptographic block boundaries are aligned with the boundaries of QUIC packets, which reduces the impact of packet loss on the decoding of content in subsequent packets;
- 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 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
