HTTP/3: Faster Connections and Better Mobility

HTTP (Hypertext Transfer Protocol) is the backbone of the World Wide Web. It powers virtually every interaction we have online today. Since its public release in 1991, HTTP has evolved alongside the Web to meet the demands of modern software.

Under the hood, HTTP sits on top of three foundational protocols: TCP, IP, and UDP. While supporting actors like DNS and DHCP are essential, TCP, IP, and UDP are the pillars that hold up the Web.

IP (Internet Protocol) is a protocol provides rules governing the format of data sent over the internet . It enables devices to communicate by assigning unique identifiers known as IP addresses.
An IP address is like a physical address that tells where the data is coming from, or needs to reach. An IP address looks like 192.168.1.1 for IPv4, and 2001:0db8:0000:0000:0000:8a2e:0370:7334 for IPv6.

Transport Protocol: TCP vs. UDP

Once we have an address, we need a way to transport the data. This is where the two main "courier" protocols come in.

TCP (Transmission Control Protocol) TCP defines how to establish and maintain a connection through which applications exchange information. It works alongside IP, often referred to together as TCP/IP. TCP is the strict, bureaucratic manager. It is perfectly accurate but can be slow. It checks every packet to ensure nothing is missing. We needed TCP for the web because a missing </html> tag could break an entire page. We couldn't afford to lose data.

UDP (User Datagram Protocol) UDP is the "sibling" protocol to TCP. It does the same job but in a fundamentally different way. UDP is fast and reckless. It fires data at the destination without checking if it arrived. It has zero latency but offers no guarantees. It doesn't "lose packets constantly" on purpose, but if a packet does get lost, UDP doesn't care and won't resend it.

The Evolution of HTTP

HTTP 1.1

We have used HTTP 1.1 since long time. It is text-based, human readable but has a major flaw that it processes requests sequentially.

If the browser needs a CSS file and a JS file, it sends a request for the CSS, waits for it to finish, and then asks for the JS. This creates a queue. If the first file gets stuck, everything behind it waits. This traffic jam is known as Head-of-Line Blocking.

HTTP 2

HTTP/2, released in 2015, introduced Multiplexing. This allowed the browser to send requests for Image A, Image B, and Script C simultaneously over a single TCP connection.

It also introduced other critical upgrades:

• Header Compression: This reduces the amount of repetitive data sent over the wire.

• Server Push: The server anticipates your needs. If you request index.html, it can push style.css and script.js over the same connection immediately—without waiting for you to ask.

However, HTTP/2 had a hidden flaw. While it seemed perfect, it could not solve Head-of-Line (HOL) Blocking at the TCP level. Because all files share a single TCP connection, you run the risk of everything getting blocked if a single packet is lost due to spotty Wi-Fi or mobile data.

🔒 HTTP/3

HTTP/3 is a revolution. It discards TCP entirely in favor of UDP (via QUIC – Quick UDP Internet Connections).

TCP is simply too rigid. The "Head-of-Line Blocking" problem inherent to TCP could not be solved without updating every operating system in the world. We needed a blank slate to build a better protocol, and UDP provided exactly that. QUIC essentially builds a new, smarter transport layer on top of UDP.

In HTTP/2, a single lost packet blocks the complete transmission. In HTTP/3, every file (or stream) has its own lane. If a packet for a single image is lost, only the stream for that specific image pauses. All other resources—CSS, scripts, text—keep downloading without interruption.

HTTP/3 also solves the mobility problem. Have you ever had a download fail when you walked out of your house and switched from Wi-Fi to 4G? That is a TCP problem (because your IP address changed). HTTP/3 solves this by using a Connection ID instead of an IP address. Even if you change networks, the server recognizes your ID, and the download resumes seamlessly.

Finally, in HTTP/3, security is baked in. It uses TLS 1.3 by default. You literally cannot have an unencrypted HTTP/3 connection. There is no http:// 🔓, only https:// 🔒.

The QUIC Lifecycle

In TCP, you shake hands to connect, then shake hands to encrypt. In QUIC, you do both at once.

A. Handshake (0-RTT Magic) During the first visit, the client sends both encryption keys and connection parameters immediately. The server acknowledges them and opens the connection. For every repeat visit, there is Zero Round Trip Time (0-RTT). Since the client has talked to the server before, it uses a saved "resumption ticket" to send encrypted data in the very first packet.

B. Data Transmission (Frames & Streams) Once connected, HTTP/3 doesn't send a single blob of data. It organizes data into a hierarchy:

1. Every file is assigned its own Stream ID. These streams are multiplexed but remain logically independent.

2. Data is chopped into Frames inside a stream.

3. Frames are wrapped inside QUIC Packets.

4. QUIC packets are wrapped inside UDP Datagrams.

The key difference: In HTTP/2, the browser knew the streams were separate, but TCP didn’t. In HTTP/3, QUIC knows they are different, so it handles packet loss per stream.

C. Header Compression (QPACK) HTTP/2 used HPACK, which relied on packets arriving in perfect order. Since QUIC allows packets to arrive out of order, HPACK breaks. Therefore, HTTP/3 introduces QPACK to handle compression without blocking.

The Architectural Shift

In HTTP/2, responsibilities were segmented into distinct protocols. HTTP/3 consolidates transport and security responsibilities into a new protocol that runs in User Space (the application).

QUIC treats UDP like a blank piece of paper. It writes its own reliability rules, encryption rules, and connection IDs onto that paper. To the outside world (the router), it looks like a simple UDP packet. But inside, it is a sophisticated, reliable QUIC packet.

By moving reliability logic from the OS Kernel (TCP) to the Application Layer (QUIC), HTTP/3 finally eliminates Head-of-Line Blocking and modernizes the web