The IETF (Internet Engineering Task Force), which develops internet protocols and architecture, has completed the formation of the RFC for the QUIC protocol and published related specifications under the identifiers RFC 8999 (version-independent properties of the protocol), RFC 9000 (transport over UDP), RFC 9001 (TLS encryption for QUIC communication), and RFC 9002 (congestion control and packet loss detection during data transmission).
The RFCs have received the status of 'Proposed Standard,' after which work will begin to elevate the RFCs to Draft Standard status, effectively meaning full stabilization of the protocol and consideration of all comments received. The HTTP/3 protocol, which defines the use of QUIC as transport for HTTP/2, is currently at the draft specification stage, but it will soon be finalized and standardized within the IETF.
Standardization of QUIC is expected to spur wider adoption of this protocol, as well as the development of extensions based on it, such as WebTransport (a technology for sending and receiving data between browsers and proxy server) and MASQUE (a connection proxying technology that extends the capabilities of SOCKS and HTTP CONNECT, using HTTPS over QUIC as the transport).
It is worth noting that the QUIC (Quick UDP Internet Connections) protocol has been developed by Google since 2013 as an alternative to the TCP+TLS combination for the web, addressing issues with long connection establishment and agreement times in TCP and eliminating delays during packet loss in data transmission. QUIC is an overlay on top of the UDP protocol, supporting multiplexing of multiple connections and providing encryption methods equivalent to TLS/SSL. During the standardization process in the IETF, modifications were made to the protocol, leading to the emergence of two concurrently existing branches: one for HTTP/3 and the other supported by Google (Chrome supports both variants, and Firefox supports the IETF version).
Key features of 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 connections instantly (0-RTT, allowing data to be sent immediately after sending the connection establishment packet in about 75% of cases) and to 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 helps eliminate ambiguity in identifying received packets and avoids 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;
- A noticeable increase in performance and bandwidth compared to TCP. For video services like YouTube, the use of QUIC has shown a reduction in buffering operations while watching videos by 30%.
Source: opennet.ru
