The IETF (Internet Engineering Task Force), responsible for the development of internet protocols and architecture, has completed the formation of the RFC for the HTTP/3.0 protocol and published related specifications under the identifiers RFC 9114 (protocol) and RFC 9204 (QPACK header compression technology for HTTP/3). The HTTP/3.0 specification has been given the status of 'Proposed Standard', after which work will begin to promote the RFC to the status of Draft Standard, which effectively means full stabilization of the protocol and consideration of all comments made. Updated versions of specifications for HTTP/1.1 (RFC 9112) and HTTP/2.0 (RFC 9113) have also been published, as well as documents defining the semantics of HTTP requests (RFC 9110) and HTTP caching control headers (RFC 9111).
The HTTP/3 protocol defines the use of the QUIC (Quick UDP Internet Connections) protocol as the transport for HTTP/2. QUIC is an overlay on the UDP protocol that supports multiplexing of multiple connections and provides encryption methods equivalent to TLS/SSL. The protocol was created in 2013 by Google as an alternative to the TCP+TLS combination for the Web, addressing issues with high connection setup times and handshakes in TCP, and eliminating delays caused by packet losses during data transmission.
Currently, support for QUIC and HTTP/3.0 is already implemented in all popular web browsers (in Chrome, Firefox and Edge, HTTP/3 support is enabled by default, while in Safari it requires enabling the 'Advanced > Experimental Features > HTTP/3' setting). On the server side, HTTP/3 implementations are available for nginx (in a separate branch and as a standalone module), Caddy, IIS, and LiteSpeed. HTTP/3 support is also provided by the content delivery network Cloudflare.
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%.
Among the changes in the HTTP/1.1 specification is the prohibition of the isolated use of the carriage return (CR) character outside of content body, i.e., in protocol elements the CR character can only be used in conjunction with the line feed character (CRLF). The chunked request composition algorithm has been refined to simplify the separation of attachment fields and header sections. Recommendations for handling ambiguous content have been added to block 'HTTP Request Smuggling' attacks, which allow inserting into the content of other users' requests in the stream between the frontend and backend.
The HTTP/2.0 specification update clearly defines support for TLS 1.3. The method for defining priorities and associated fields in headers has been moved to the deprecated category. The unadopted mechanism for connection upgrade from HTTP/1.1 is marked as deprecated. Requirements for field names and value verification have been simplified. Some previously reserved frame types and parameters have been proposed for use. The prohibited header fields related to connections are more precisely defined.
Source: opennet.ru
