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.
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.
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.
Developed by Google, QUIC runs over UDP—a connectionless, lightweight protocol. Let’s explore three key benefits of QUIC:
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) |
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 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.
The image below is an overview of how these layers relate to one other.
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 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.
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.
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 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.
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.
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.
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.
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.
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.
The adoption of HTTP/3 may present certain challenges that need to be addressed during its implementation, some of which are outlined below.
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.
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.
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.
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:
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.
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!