Author:
Kostadin Spiridonov | .NET Engineer at Coherent Solutions Bulgaria
What is HTTP/3?
HTTP/3, the most recent iteration of the HTTP protocol, brings forth advancements in performance, reliability, and security. A crucial aspect in achieving these improvements lies in the substitution of the traditional TCP protocol with QUIC (Quick UDP Internet Connections), which operates on UDP. Designed to tackle challenges related to network switching, particularly on mobile devices, QUIC addresses concerns that were not prevalent during the early development of Internet protocols, given the less portable nature of devices at that time.
While HTTP/3 retains similar semantics to its earlier versions, such as the use of identical request methods, status codes, and message fields, it diverges in its encoding and session state management methods. Notably, its implementation of QUIC contributes to reduced latency and faster load times in real-world scenarios when compared to previous iterations. In fact, HTTP/3 can be more than three times faster than HTTP/1.1 in certain cases, making it a significant advancement in terms of speed and performance.
Why do we need HTTP/3?
Layering is a fundamental and crucial concept in network protocols, facilitating the seamless integration of features by building one protocol on top of another. A prime example of this is HTTP’s implementation over TLS, where HTTP can leverage the existing encryption capabilities provided by TLS without having to incorporate encryption functionalities itself. This approach not only promotes modularity and reusability but also enhances the overall efficiency and security of the system.
Most Internet applications rely on TCP as an internal transport layer due to its assurance of complete data delivery. However, the advent of technological evolution has exposed certain inefficiencies within TCP, prompting the development of more efficient alternatives. TCP was not originally designed with maximum efficiency in mind, leading to issues such as head-of-line blocking and full-roundtrip handshakes, which notably impact the performance of the HTTP protocol.
Although attempts have been made to address TCP’s deficiencies through extensions, deploying these fixes on an Internet-wide scale has proven to be a challenging task. Consequently, the practical feasibility of evolving TCP has become increasingly unlikely. This paved the way for the emergence of QUIC, which ultimately gave rise to the development of HTTP/3. By replacing TCP with QUIC, HTTP/3 aims to overcome the limitations of its predecessors and deliver higher efficiency, improved performance, and enhanced user experience in the evolving landscape of the Internet.
What is QUIC?
QUIC serves as a generic transport protocol, similar to TCP, and finds application in various use cases beyond HTTP and web page loading. Examples include DNS, SSH and more, as all these can utilize QUIC for their communication needs.
QUIC is designed to operate on top of UDP instead of directly on IP. The choice of UDP as the underlying transport protocol for QUIC is motivated by the fact that UDP is widely supported across the Internet. Since UDP is already well-established and commonly used, there is no requirement for all devices to undergo updates or modifications to accommodate the new QUIC protocol.
The major changes in QUIC compared to TCP
Deep integration with TLS
As the Internet’s security landscape has evolved towards a “secure by default” approach, QUIC follows this trend by incorporating encryption directly into the protocol. This integration offers enhanced security, faster connection setup and simplified evolution.Supports multiple independent byte streams
Unlike TCP, which operates on a single, ordered byte stream, QUIC allows for the concurrent transmission of multiple data streams within a single connection. Each of these streams can be processed independently, enabling improved parallelism and reduced latency in communication.Uses connection IDs
Unlike TCP, which relies on a combination of IP addresses and port numbers to identify connections, QUIC introduces connection IDs to uniquely identify each connection independently. Benefits of using connection IDs in QUIC include: Connection Migration, Improved Security, Multipath Support, Faster Handshake RecoveryUses frames
Frames are individual units of data that allow QUIC to encapsulate various types of information and organize them efficiently within a single connection. Benefits: Modularity and Efficiency, Simplified Multiplexing, Stream Control, Extensibility
HTTP/3 in .NET world
HTTP/3 utilizes the QUIC transport protocol as its backbone. In the .NET implementation of HTTP/3, Microsoft has integrated the MsQuic library, enabling seamless QUIC functionality within the ASP.NET Core ecosystem. This integration allows developers to harness the benefits of HTTP/3 and QUIC without compromising on platform dependencies.
In ASP.NET Core 6.0 (Preview), HTTP/3 is introduced as a preview feature since the HTTP/3 specification had not been fully finalized at that time. As a preview feature, it allows developers to explore and experiment with HTTP/3 functionality.
With the release of ASP.NET Core 7.0, HTTP/3 support is now fully integrated and readily available. Developers can take advantage of the enhanced performance and security features that HTTP/3 offers to deliver faster and more reliable web applications.
Configuring the HttpClient to use HTTP/3 in ASP.NET Core 7.0 is a straightforward process. Simply set the HttpRequestMessage.Version property to HttpVersion.Version30, indicating that HTTP/3 should be used for communication.
Kestrel, the default web server for ASP.NET Core, also requires configuration to enable HTTP/3 support. In ASP.NET Core 7.0, developers can use the ListenOptions.Protocols property and set it to HttpProtocols.Http3, enabling the server to handle incoming HTTP/3 requests.
When developing applications that are configured to take advantage of HTTP/3, it’s essential to ensure backward compatibility by also supporting HTTP/1.1 and HTTP/2. This is because not all clients and servers may support HTTP/3 yet, and having support for multiple protocols ensures that your application can be accessed by a broader range of users.
In ASP.NET Core 8.0 a notable change takes place: HTTP/3 is now enabled by default, coexisting harmoniously alongside HTTP/1.1 and HTTP/2.