As the cornerstone of the Internet, Hypertext Transfer Protocol (HTTP) has always played an important role in web page loading, video streaming, and applications obtaining data.
Last year, the Internet Engineering Task Force (IETF), which is responsible for defining Internet technologies, standardized the latest version of the protocol, HTTP/3. Since then, HTTP.3 and related QUIC protocols have rapidly become popular on public networks. Although different sources and measurement methods give slightly different results, it is currently generally believed that 19% to 50% of the world's web servers and networks support HTTP/3.
Due to the widespread adoption of these new protocols by major companies such as Google and Meta, we believe that a significant portion of current Internet traffic is already using HTTP/3.
In this article, I'll provide some background on what problems HTTP/3 solves, how it performs, why it's so rapidly adopted, and what obstacles HTTP/3 still faces that need to be overcome.
Why do we need HTTP/3?
Network protocols describe how data is communicated between two entities on a network (usually a user device and a web server). Because there are multiple companies on the market developing software for the network, communication protocols must ensure standardization so that all software can "interoperate" with each other. In other words, software can understand each other based on following the same rules.
In practice, we often do not use a single protocol, but a combination of multiple protocols at the same time. Each agreement has its own role and rules (see Figure 1 for details). This design is to ensure flexibility and reusability - no matter whether you are using Wi-Fi, fixed network or 4G/5G, you can use the exact same HTTP logic.
Figure 1 The protocol stack of HTTP/2 and HTTP/3, how to combine multiple protocols to provide complete Internet functions
Many of the early Internet protocols were set as standards as early as the 1980s and 1990s, which means they were designed with the needs and limitations of decades ago in mind. While some of these protocols have stood the test of time, many are clearly outdated. Most problems can be solved through workarounds and some tricks, but there are also times when changes have to be made. The most typical one is the Transmission Control Protocol (TCP), which is used to ensure that data can be transmitted reliably to and from the Internet.
Why TCP is no longer suitable for today’s Web
The prerequisite for the normal operation of HTTP/1.1 and HTTP/2 is based on TCP. Specifically, before HTTP requests/responses can be exchanged between the client and server, a TCP connection must be established.
Over time, there have been efforts to update TCP and address some of its efficiency issues—for example, TCP treats a web page as a single file rather than a collection of hundreds of separate files. While some updates have been successful, most high-impact updates, such as TCP Multipath and TCP Fast Open, took nearly a decade to actually hit the public Internet.
The main challenge in innovating TCP is that there are thousands of devices on the Internet, each with its own implementation of the TCP protocol. In addition to the mobile phones, laptops, and servers that everyone thinks of immediately, there are also other types of "middle devices" such as routers, firewalls, and load balancers. In other words, if we want to update TCP, we have to wait for most of these devices to update their own protocol implementations, which is obviously an arduous process that takes several years.
QUIC Solution
Faced with this almost unsolvable problem, the most reliable way is to directly introduce a new solution and directly replace TCP. This alternative is the QUIC protocol, but many people half-jokingly refer to it as TCP 2.0. This nickname is actually not inappropriate, because QUIC does contain many of the same advanced features as TCP, but with a series of key adjustments.
The biggest change is QUIC’s deep integration with the Transport Layer Security (TLS) protocol. TLS is responsible for encrypting sensitive data on the network, which is the S (Secure) in HTTPS. Under the TCP protocol, TLS only encrypts the actual HTTP data (see Figure 2); with QUIC, TLS also encrypts most of the QUIC protocol itself. In other words, metadata in TCP that is visible (and changeable) to all middleware (such as packet numbers, connection closing signals, etc.) will now be available only to clients and servers in QUIC.
Figure 2 Encryption differences between TCP+TLS and QUIC. As you can see, it is not just HTTP data that is encrypted in QUIC
Additionally, because QUIC is more securely encrypted, changes to it or the addition of new features is much simpler than TCP - i.e. only clients and servers need to be updated, since the middleware cannot decrypt the metadata anyway. This makes QUIC a future-proof protocol that can help us quickly solve emerging challenges.
Of course, this additional encryption mechanism also helps enhance the overall security and privacy of the new protocol. While TCP+TLS is ideal for protecting sensitive personal data such as credit card or email content, it is still vulnerable to sophisticated (privacy) attacks. And with the rapid development of AI technology, the threshold for implementing these attacks is getting lower and lower. By further encrypting this type of metadata, the QUIC protocol will undoubtedly be better able to deal with orchestrated malicious attacks.
QUIC also includes many other security-related features, including protection against distributed denial-of-service (DDoS) attacks, as well as protection against amplification and RETRY packets.
Finally, QUIC also brings a number of efficiency and performance improvements compared to TCP, including faster connection handshakes (see Figure 3), elimination of "head of line blocking" problems, better packet loss detection/recovery, and processing Methods for users to switch networks (we will introduce this in detail in subsequent articles).
Figure 3 QUIC is set up to have faster connection speeds because it combines a "transport" three-way handshake with a TLS encrypted session, outperforming the two separate processes in TCP+TLS
What we really need is not HTTP/3, but QUIC
Initially, we also tried to retain HTTP/2 and make incremental adjustments, hoping to use QUIC at the bottom layer (after all, that was the point of retaining so many collaborative elements and reusable protocols). But it's obvious that there are huge differences between QUIC and TCP, and HTTP/2 is simply not compatible with them all. Therefore, the Internet Engineering Task Force decided to make a new version of HTTP specifically for QUIC, which is now HTTP/3.
HTTP/3 is almost the same as HTTP/2. The main difference between the two is reflected in the technical implementation of various functions on QUIC/TCP. But because HTTP/3 can take advantage of all the new features of QUIC, it will result in better performance when loading web pages and streaming video. It is precisely this advantage that has allowed HTTP/3 to be widely recognized and quickly adopted by the market.