Cloudflare Company to provide support for the HTTP/3 protocol in NGINX. The module is made in the form of an add-on over the library developed in Cloudflare with the implementation of the transport protocol QUIC and HTTP/3. The quiche code is written in Rust, but the NGINX module itself is written in C and accesses the library using dynamic linking. Developments under the BSD license.
To assemble, just download to nginx 1.16 and quiche libraries, and then rebuild nginx with options "--with-http_v3_module --with-quiche=../quiche". When building, TLS support must be based on the BoringSSL library ("--with-openssl=../quiche/deps/boringssl"), using OpenSSL is not yet supported. To accept connections, you need to add the listen directive with the βquicβ flag to the settings (for example, βlisten 443 quic reuseportβ).
From the client side, HTTP/3 support has already been added to experimental builds of Chrome Canary and the curl utility. On the server side, until now, it was required to use stand-alone . The ability to process HTTP / 3 in nginx will greatly simplify the deployment of servers with HTTP / 3 support and make test implementation of the new protocol more accessible. The appearance of regular support for HTTP / 3 in nginx in the 1.17.x branch for 6-12 months.
Recall that HTTP/3 standardizes the use of the QUIC protocol as a transport for HTTP/2. 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.
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.
- 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;
- 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