What Is HTTP/3 and How Does It Differ from HTTP/2?

Hypertext Transfer Protocol (HTTP) is the core protocol of the World Wide Web which acts as a portal for communication between web browsers and servers. There are various versions of HTTP, of which the most recent are HTTP/2 and HTTP/3. This article provides a comparative analysis of HTTP/2 and HTTP/3 and explains why you should switch to the latter.

What Is HTTP/3?

HTTP/3 is a significant advance over HTTP/2. It is established over QUIC, which is a transport protocol notable for features such as improved performance, reduced latency, enhanced security, and better handling of network fluctuations.

The Third Generation of the Protocol

HTTP/3 is the latest generation of HTTP. The table below details the earlier versions, their year of release, specification and key features.

HTTP Version	Released	Specification	Key Features
HTTP/0.9	1991	No RFC number	One-line protocol with only GET
HTTP/1	1996	RFC 1945	Status codes, HTTP header, POST and HEAD
HTTP/1.1	1997	RFC 9112	Keep-alive connection, more HTTP functionalities
HTTP/2	2015	RFC 9113	TCP (transmission control protocol), a new binary framing layer, multiplexing, header compression (HPACK), server-side push
HTTP/3	2022	RFC 9114	QUIC over UDP (user datagram protocol), TLS by default, header compression (QPACK), connection ID

HTTP/3 supersedes HTTP/2 because it implements QUIC instead of TCP. So, let us examine why QUIC is better than TCP and how it keys into HTTP/3’s superiority.

HTTP over QUIC

Developed by Google, QUIC runs over UDP—a connectionless, lightweight protocol. Let’s explore three key benefits of QUIC:

• TCP, employed by HTTP/2, transmits and delivers data streams in the exact order the sender generated them. Although this approach prevents packet loss, it is also the predominant cause of HTTP/2’s HOL blocking issue. QUIC, on the other hand, is connectionless and enables multiplexing at the transport layer, preventing TCP’s head-of-line blocking issue.
• Since UDP does not require a client-server connection, it facilitates data delivery via the most optimal routes. However, this approach has no data retransmission mechanism, so it usually causes packet loss. QUIC addresses this via multiplexed connections at the higher level (to enable the transmission of multiple data streams simultaneously and independently) and prevent packet losses in one stream from affecting others.
• QUIC offers bandwidth estimation from both server and client directions, to determine how much data a network can transmit within a given session, and forward error correction (FEC) capabilities (via FEC packets) to prevent errors in unstable network environments, further enhancing performance.

Other Differences Between HTTP/2 and HTTP/3

Beyond the differences in their transport layer protocol (TCP vs QUIC), there are other contrasts between HTTP/2 and HTTP/3:

Differentiators	HTTP/2	HTTP/3
Transport layer protocol	TCP	QUIC, which operates over UDP
Multiplexing & head-of-line (HOL)	Often encounters head-of-line blocking issues for multiplexed streams due to limitations in byte stream abstraction	Offers multiplexing without head-of-line blocking due to UDP’s out-of-order delivery
Error handling	Fewer error handling capabilities	Enhanced error handling capabilities due to QUIC
TLS encryption	TLS is optional	TLS is embedded in QUIC and by default in HTTP/3
Connection migration	Does not support connection migration	Supports seamless connection migration via connection IDs (CIDs) (explained below)

HTTP/2 and HTTP/3 Stack Comparison

Apart from the differences in their offerings, HTTP/2 and HTTP/3 are also architecturally different.

Each of the components in the diagram—and how they differ between HTTP/2 and HTTP/3—are explained below.

HTTP Semantics

HTTP semantics are the resource metadata attached to requests and responses. They include request header fields and response status codes. HTTP/3 and HTTP/2 semantics are similar in terms of data format and request/response types. However, their arrangement order differs.

• HTTP/2 has a distinct application layer (HTTPS,) an optional security layer (TLS,) and a transport layer (TCP), stacked in that order.
• The layers in HTTP/3 are less distinct, with HTTPS being the application layer, both HTTPS and QUIC forming a built-in security layer, and both QUIC and UDP forming the transport layer.

The image below is an overview of how these layers relate to one other.

Header Compression

This is a mechanism used to compress headers (including IP, UDP and TCP headers) of data packets before they are sent, to quicken packet transmission, reduce bandwidth consumption, and limit network overhead. HTTP/2 uses HPACK for header or field compression, while HTTP/3 uses QPACK. Although both HPACK and QPACK are efficient, they work differently, and while HPACK is prone to HOL, QPACK is not.

Server Push and Prioritization

Server push involves servers preemptively sending resources to clients in order to reduce latency. Both HTTP/2 and HTTP/3 support server push. However, in HTTP/3, clients can set the number of acceptable pushes via the push stream ID to reduce wasted bandwidth.

Stream Multiplexing

Both HTTP/2 and HTTP/3 support multiplexing, allowing multiple requests and responses to be sent simultaneously over a single connection. But TCP, employed by HTTP/2, considers every request (including multiplexed ones) as a single byte stream. This approach employed by TCP is usually the cause of HOL issues during multiplexed streaming in HTTP/2. In HTTP/3, the issue is addressed via implementation of UDP’s out-of-order delivery, where each byte stream is transported independently over the network.

TLS (Transport Layer Security) Encryption

Both protocols offer TLS encryption. But in HTTP/2, TLS is optional, and the TLS encryption is via the common TLS 1.2 and TLS 1.3 protocols. In HTTP/3, TLS encryption is provided by default via QUIC’s key exchange mechanism, universally reducing the risk of eavesdropping, data tampering, and other security threats.

Session Resumption/0-RTT

Session resumption involves reusing parameters used in previous exchanges without reinitiating a full handshake. In HTTP/2, session resumption is implemented using the TLS session tickets mechanism, where at least two rounds of handshakes—TCP & TLS—are required before reconnect. On the other hand, HTTP/3 leverages QUIC’s 0-RTT (zero round trip time resumption) feature, which enables clients to send encrypted data in the first packet of the handshake, allowing for faster resumption of previous sessions.

IPv4 / IPv6

IP addresses are used to create virtual connections between devices and networks. IPv4 uses 32-bit addresses while IPv6 uses 128-bit addresses. Both HTTP/2 and HTTP/3 operate both IP types.

Other Distinctive Features of HTTP/3

While the stack comparison of their respective architecture reveals important reasons for HTTP/3’s superiority, there are yet more features which give it an edge over HTTP/2.

Fewer Handshakes, Faster Connection

HTTP/3 establishes efficient connections and reduces latency by reducing the number of handshakes required to establish a connection. In HTTP/2, establishing a connection involves a series of handshakes between the client and server. These handshakes introduce additional round trips, increasing the latency of establishing a connection.

Seamless Connection Migration with CID

The connection ID (CID) feature in HTTP/3 eases migration whenever a client switches networks or devices. Thanks to the CID feature, clients can maintain a stable connection without requiring new handshakes. CID works by assigning a unique identifier to each connection, and when the client switches networks or devices, it simply updates the network information associated with the connection while keeping the same CID.

This is particularly beneficial in scenarios such as switches from Wi-Fi to cellular or vice versa. The seamlessness of the migration ensures smoother web browsing, and reduces the likelihood of connection hijacking or interception.

Adoption of HTTP/3

Several organizations have recognized the benefits of HTTP/3 and are actively implementing it. Regarding browser support, Google Chrome, Mozilla Firefox, Opera and Microsoft Edge have implemented HTTP/3. However, Safari, the web browser developed by Apple, currently does not implement the protocol.

The readiness of global companies and the majority of browsers to use HTTP/3 is another proof of its superiority over HTTP/2. And as challenges associated with its implementation are overcome, HTTP/3’s adoption will continue to rise, leading to wider support across browsers and platforms.

Challenges of HTTP/3 Implementation

The adoption of HTTP/3 may present certain challenges that need to be addressed during its implementation, some of which are outlined below.

Compatibility with Existing Infrastructure

To switch to HTTP/3, you must modify your existing infrastructure, including servers and load balancers. Even after switching, compatibility could still be a challenge, especially if your organization is large and/or has complex network setups.

Firewall Compatibility

The QUIC transport protocol, employed by HTTP/3, encrypts data packets in their entirety, from payload to metadata. Encryption, although beneficial, makes access to the data packet difficult. However, firewalls need access to the packet; without access to it, clients are exposed to cyberattacks.

Client-Side Browser Support and Server Implementation

Although many browsers have embraced HTTP/3, Safari has not. Implementing HTTP/3 on the server-side requires expertise, and you may even need to update your server infrastructure.

Compatibility with existing HTTP/2 or HTTP/1.x implementations is another challenge. Compatibility is essential for seamless transfer of requests across the different protocols—especially important during the gradual global transition to HTTP/3. While possible, executing the switch without disrupting existing services and connections is difficult.

HTTP/3 for CDN

Content delivery networks (CDNs) cache content in multiple server locations across the globe. As HTTP/3 adoption continues, its tangential benefit to CDNs will also continue to expand, encouraging CDN providers to implement the protocol, and thereby boosting its adoption. The HTTP/3—CDN romance can offer the following benefits:

• Native encryption: Since HTTP/3 provides TLS encryption, incorporating HTTP/3 with CDNs can facilitate native encryption rather than relying on out-of-the-box TLS encryption for caches. This bolsters the security of native and third-party networks.
• Reduced connection establishment: Using QUIC, HTTP/3 minimizes connection time and provides seamless multiplexing and faster error detection. CDNs leveraging HTTP/3 will greatly benefit from this reduced latency, improving the overall performance and reliability of content delivery.

Although these benefits are intriguing, CDN providers must first invest in HTTP/3 support by updating their infrastructure and reconfiguring their edge servers in order to deliver the benefits to their customers.

Conclusion

By building on the strengths of HTTP/2 and addressing its weaknesses, HTTP/3 offers improved performance, enhanced security, reduced latency and better handling of network conditions, making it a promising protocol for the future of web communications.

At Gcore, we’re always striving to make the internet a better place, so we’re actively developing and investing in our global Edge network (CDN) to support HTTP/3 and make it available for everyone. Once it’s ready, you will be able to enjoy a faster and more secure connection for your website and applications. Watch this space for updates!

Explore Gcore CDN