Skip to main content

5 key HTTP/3 facts every Enterprise Architect needs to know

HTTP/3 is on its way to becoming commonplace communication protocol. Learn how it improves upon HTTP/1.1 and HTTP/2 to provide faster web services.
Rocket ship shooting off into space at night

Photo by NASA on Unsplash

HTTP/3 is the next-generation communication protocol for applications running on the internet. The protocol is not yet being used for general purposes in the way HTTP/1.1 and, to some extent, HTTP/2 are, but nonetheless many companies are preparing for its arrival. At some point, it will gain wide adoption. Thus, getting a general understanding of HTTP/3 is useful for Enterprise Architects interested in developing next-generation architectures.

The following is a list of five things that we think every Enterprise Architect needs to know about HTTP/3.

  1. HTTP/3 is driven by the need for speed
  2. HTTP/3 evolved from QUIC
  3. HTTP/3 uses UDP
  4. HTTP/3 addresses the head-of-line blocking problem
  5. HTTP/3 injects QUIC into the OSI and TCP/IP Models

Let's look at the details of each.

HTTP/3 is driven by the need for speed

The driving force behind the advent of HTTP/3 is to make information traveling over the internet go faster in a more efficient manner. The internet has an insatiable appetite for speed, particularly as the demand for video, continuous event messaging, and other types of streaming data proliferate to a broader set of applications. HTTP/3 is intended to meet this demand.

HTTP/2 is fast, but it has design limitations that HTTP/3 addresses. You'll read about these limitations and how HTTP/3 addresses them in a moment. The bottom line is that HTTP/3 is designed for greater efficiency in web communication. So, let's look at how HTTP3 evolved.

HTTP/3 evolved from QUIC

QUIC is an acronym for Quick UDP Internet Connections. QUIC was created at Google by Jim Roskind, who released the first version of the design specification in 2012. In 2018 QUIC was combined with the HTTP working group of the Internet Engineering Task Force (IETF)  to create the HTTP/3 specification. The goal is to have HTTP/3 become a standard for the internet on the order of HTTP/1.1 or HTTP/2.

Whereas HTTP/1.1 and HTTP/2 use the Transmission Control Protocol (TCP) as their data transport protocol, QUIC was designed from the beginning to work with User Datagram Protocol (UDP). Using UDP incurs some tradeoffs, which you'll read about below, but one of the main benefits that UDP offers is that it's a faster, more efficient way to exchange data than its TCP counterpart.

HTTP/3 uses UDP

As mentioned above, HTTP/1.1 and HTTP/2 use TCP as their transmission protocol. HTTP/3 and QUIC, the protocol from which HTTP/3 was derived, use UDP. The difference matters. Here's why:

Fundamentally UDP is a fire and forget protocol. You send a data packet to a target, and that's that! TCP requires a lot of back and forth data exchange between sender and target to establish a network connection. Then, even after the connection is established, there's more back and forth because TCP requires that the sender receive an acknowledgment from the target every time a data packet is sent. This back and forth eats up time. UDP has no back and forth connection handshake, nor does it require acknowledgment from a target when data packets are received. It just sends packets of data to the destination and hopes for the best. (See Figure 1, below.)

diagram depicts tcp handshake
Figure 1: TCP requires a handshake to establish a network connection between sender and target; UDP does not.

Eliminating all the back and forth activity makes UDP faster than TCP. But, there is a tradeoff. Under UDP, packets can get lost. Because there's no acknowledgment from the target, the sender never knows about the packet loss, and thus there's no way to recover. TCP, on the other hand, is designed to recover from packet loss. TCP notices that no acknowledgment has been received and resends the packet. TCP is slower, but it is fault-tolerant. Thus the tradeoff. TCP gives you fault tolerance. UDP gives you speed. The trick is to get both fault tolerance and speed. HTTP/3 provides both. Also, HTTP/3 addresses another problem: Head-of-line blocking.

HTTP/3 addresses the head-of-line blocking problem

One of the challenges that HTTP/3 addresses is the network latency bottleneck created by the head-of-line block. To understand the nature of head-of-line blocking, it's useful to review how data travels over the internet.

Essentially, head-of-line blocking is when one request blocks another from completing. The problem exists under HTTP/1.1 and HTTP/2 because these use TCP as the transport protocol. Take a look at Figure 2 below. It shows an illustration of the head-of-line blocking problem. An explanation follows.

tcp handshake requires acknowledgement or additional transmissions blocked
Figure 2: To facilitate the continuous flow of data packets, the TCP protocol requires an acknowledgment to be sent to the sender once the target receives a packet.

Whenever a client makes an HTTP request for data, in this case, the .jpg file described above in Figure 2, that data is broken up into packets sent across the network to the target and then reassembled upon arrival. As mentioned above, TCP uses a send-acknowledge pattern. Once the target receives a data packet, it replies to the sender with an acknowledgment. After the sender receives the acknowledgment, it sends another data packet. If no acknowledgment is received within a certain timespan, for example, half a second, the sender will try to send the packet again or just time out.

In the Figure 2 example above, you can see that Packet 1 is sent, and an acknowledgment is received. Packet 2 is sent, but the sender never receives the acknowledgment. Thus Packet 2 just sits in limbo. Packet 3 can't be sent because the acknowledgment for Packet 2 was never received. Packet 3 is blocked by Packet 2's exchange failure. This is what head-of-line blocking is about: A data packet can't be sent because a previous one has not been acknowledged. As you can imagine, the performance implications can be considerable.

HTTP/3 avoids the head-of-line blocking problem because, as you read above, UDP just sends packets; there is no acknowledgment in play. Thus, data exchange performance improves. However, because UDP doesn't expect an acknowledgment, data packets can get lost. This is a problem. HTTP/3 addresses the issue by modifying the OSI model by injecting QUIC technology into the stack, the details of which we describe next.

HTTP/3 injects QUIC into the OSI and TCP/IP Models

Moving data over a computer network is a complex undertaking. Doing something as simple as viewing a picture of a cat posted on Facebook requires a lot of technology and process. Without a standard way of doing things, the world of networking would be a collection of proprietary factions fighting it out for market dominance. It's hard to build something as ubiquitous as the internet under such conditions.

Fortunately, the days of the Wild West of network computing have long passed. Today we live in a world of generally accepted models and standards to conduct networking on a worldwide basis. The two prevalent models for internet networking are the OSI Model and the TCP/IP Model.

Both models describe the layers of technology required to construct and operate a non-proprietary worldwide network. The OSI Model has seven layers, while the TCP/IP Model has four layers. At the conceptual level, they are similar. They both describe how to connect two computers on a network to pass data back and forth.

Figure 3 below illustrates the various layers of the OSI and the TCP/IP models. Also, it shows how HTTP/3 maps against the models.

diagram of OSI and TCP/IP models and HTTP/3 mapped
Figure 3: Mapping HTTP/3 and QUIC against the OSI and TCP/IP models.

The important thing to understand about HTTP/3 with regard to the OSI and TCP/IP models is that HTTP/3 injects QUIC into the network layering. The reason for the injection is that QUIC provides fault tolerance for data packet transmission under UDP. QUIC lives between transport and the application layers of the OSI and TCP/IP models. (See Figure 3, above.)

Remember, UDP is a fire and forget protocol. If a packet gets lost in the network, it's tough luck. Packet loss is acceptable for a few use cases, but most applications depend on reliable packet transmission. While TCP ensures reliable packet transmission, it's slower than UDP. However, when you combine UDP with QUIC, you get the best of both worlds: speed with reliable packet transmission. The result is HTTP/3.

Putting it all together

The need for speed has been a driving force in network architecture for more than a half-century, back to a time when dumb terminals connected to mainframe computers miles away. The rise of the internet and the proliferation of streaming data only accelerated demand.

HTTP/3 is well-positioned to make the internet go faster, but it still has a ways to go to become a generally adopted protocol. Today, all the major browsers support it, but it only has a 19% adoption rate among websites as of May 2021. Clearly, the obstacle to overcome is adoption on the server-side. Facebook and Google have HTTP/3 enabled on the server-side. Surprisingly, as of this writing, Twitter, Uber, Apple, and LinkedIn do not.

How to check if a server supports HTTP/3

You can use tools such as or to see if a website supports HTTP/3.

Still, if history has shown us anything, it's that when a protocol exists that will make the Internet go faster, it will be adopted. It's only a matter of time. HTTP/3 is on the path to wide acceptance that will make it an essential part of any Enterprise Architect's technology landscape. Given the impending adoption rate on the horizon, HTTP/3 is a protocol that's worth learning about sooner rather than later.

Topics:   Telecom   Infrastructure   Messaging patterns  
Author’s photo

Bob Reselman

Bob Reselman is a nationally known software developer, system architect, industry analyst, and technical writer/journalist. More about me

Navigate the shifting technology landscape. Read An architect's guide to multicloud infrastructure.


Privacy Statement