The IETF (Internet Engineering Task Force), which develops the protocols and architecture of the Internet, 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 received the status of a "Proposed Standard", after which work will begin on giving RFC the status of a draft standard (Draft Standard), which actually means the complete stabilization of the protocol and taking into account all the comments made. At the same time, updated versions of the specifications for the HTTP/1.1 (RFC 9112) and HTTP/2.0 (RFC 9113) protocols were 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 add-on to 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 TCP + TLS for the Web, solving the problem of long connection setup and negotiation time in TCP and eliminating delays due to packet loss during data transfer.
At present, QUIC and HTTP/3.0 support is already implemented in all popular web browsers (Chrome, Firefox, and Edge have HTTP/3 support enabled by default, while Safari requires the "Advanced > Experimental Features > HTTP/3" setting to be enabled). On the server side, HTTP/3 implementations are available for nginx (in a separate branch and as a separate module), Caddy, IIS, and LiteSpeed. HTTP/3 is also supported by the Cloudflare content delivery network.
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%.
From the changes in the HTTP/1.1 specification, one can note the prohibition on the separate use of the carriage return (CR) character outside the body with the content, i.e. in protocol elements, the CR character can only be used in conjunction with the newline character (CRLF). The chunked request layout algorithm has been improved to simplify the separation of attached fields and sections with headers. Added guidelines for handling ambiguous content to block "HTTP Request Smuggling" attacks that can intrude into the content of other users' requests in the flow between the frontend and backend.
An update to the HTTP/2.0 specification explicitly defines support for TLS 1.3. Deprecated the prioritization schema and related header fields. The outdated HTTP/1.1 connection update mechanism has been deprecated. Reduced requirements for checking field names and values. Some previously reserved frame types and parameters have been proposed for use. The forbidden header fields related to the connection are more precisely defined.
Source: opennet.ru