Microsoft about the open-source code of the library with the implementation of the network protocol . The code is written in C and under the MIT license. The library is cross-platform and can be used not only on Windows but also on Linux, utilizing or OpenSSL for TLS 1.3. Support for additional platforms is planned in the future.
The library is based on the code of the msquic.sys driver provided in the Windows 10 (Insider Preview) kernel to support HTTP and over QUIC. This code is also used for implementing HTTP/3 in the internal Windows stack and in .NET Core. Development of the MsQuic library will be conducted entirely on GitHub, utilizing public reviews, pull requests, and GitHub Issues. An infrastructure has been prepared to test each commit and pull request against a set of over 4000 tests. After stabilizing the development environment, changes from external developers are planned to be accepted.
MsQuic can already be used to create servers and clients, but not all functionality specified in the IETF specification is currently available. For example, there is currently no support for 0-RTT, client migration, Path MTU Discovery, and server preferred address management. Noteworthy implemented features include optimizations for maximum throughput and minimal latency, support for asynchronous input/output, RSS (Receive Side Scaling), and the ability to combine incoming and outgoing UDP streams. MsQuic's implementation has been tested for compatibility with experimental branches of the Chrome and Edge browsers.
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 comparable to TLS (essentially QUIC provides the option to use TLS 1.3 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
