Cloudflare to ensure support for the HTTP/3 protocol in NGINX. The module is implemented as an extension built on the library developed by Cloudflare with the implementation of the QUIC transport protocol and HTTP/3. The quiche code is written in Rust, but the module for NGINX is written in C and interacts with the library through dynamic linking. Developments under the BSD license.
To build it, simply download NGINX 1.16 and the quiche library, after which rebuild NGINX with the options ‘--with-http_v3_module --with-quiche=../quiche’. During the build, TLS support must be based on the BoringSSL library (‘--with-openssl=../quiche/deps/boringssl’), OpenSSL support is not yet available. To accept connections, the configuration needs to include the listen directive with the ‘quic’ flag (for example, ‘listen 443 quic reuseport’).
In client software, HTTP/3 support has already been added to experimental builds of Chrome Canary and the curl utility. On the server side, it was still necessary to use limited standalone . The capability to process HTTP/3 in NGINX will significantly simplify the deployment of servers supporting HTTP/3 and make it easier to test the new protocol. Native support for HTTP/3 in NGINX is expected in the 1.17.x branch within 6-12 months.
It should be noted that HTTP/3 standardizes the use of the QUIC protocol as a transport for HTTP/2. The protocol (Quick UDP Internet Connections) has been developed by Google since 2013 as an alternative to the TCP+TLS stack for the Web, addressing issues with long connection setup and negotiation times in TCP and eliminating delays when packet loss occurs during data transfer. QUIC is an extension of the UDP protocol, supporting multiplexing of multiple connections and providing encryption methods equivalent to TLS/SSL.
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.
- 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;
- 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
