Picture a supermarket with one checkout. You only have a bottle of water, but the person in front of you has a full trolley and a coupon dispute. You wait. Everyone waits.

That was the web on HTTP/1.1. A modern page needs dozens of files: HTML, CSS, JavaScript bundles, fonts, images, API calls. And for years, browsers fetched them through a few narrow queues where one slow item held up everything behind it.

HTTP/2 and HTTP/3 are, at heart, two attempts to fix that queue. The interesting part is that the second one had to throw out TCP to finish the job.

The problem with HTTP/1.1

On a single HTTP/1.1 connection, a request goes out and the response must come back before the next one can use that connection. (Pipelining existed on paper, but browsers effectively never used it.)

Browsers worked around this by opening several connections per host, typically about six. Developers worked around that with a whole collection of hacks:

• Concatenation: bundle all your JavaScript into one giant file so it's one request.
• Sprites: combine icons into one image and show slices of it with CSS.
• Domain sharding: serve assets from static1.example.com and static2.example.com to get more parallel connections.
• Inlining: stuff small images into CSS as data URIs.

Each new connection also costs a TCP handshake and a TLS handshake before a single byte of your page arrives. On a phone with a weak signal, that adds up quickly.

HTTP/2: many conversations on one line

HTTP/2 keeps the meaning of HTTP the same (methods, status codes, headers, URLs) and changes how it travels on the wire.

Multiplexing

Instead of one request at a time, HTTP/2 splits every request and response into small binary frames, each tagged with a stream ID. Many streams share one connection, and their frames are interleaved. The browser can ask for the CSS, three scripts and ten images at once, and the responses come back in pieces as they're ready.

Back to the supermarket: it's now one very fast checkout that scans a few items from each customer in turn, so the water bottle doesn't wait for the trolley.

Header compression

HTTP headers are surprisingly repetitive. Every request to your site sends the same cookies, the same user agent, the same accept headers. HTTP/2 uses HPACK, which keeps a table of headers already sent on the connection and refers to them by index instead of repeating them. For API-heavy apps with large cookies or tokens, that's a real saving.

Prioritisation (and the feature that didn't make it)

HTTP/2 also let browsers hint which resources matter most. It shipped with server push too, where the server sends files before the browser asks. In practice push was hard to get right and often sent things the browser already had cached. Major browsers have since dropped support, so don't build on it.

The catch: head-of-line blocking moved, it didn't disappear

HTTP/2 fixed head-of-line blocking at the HTTP level. But all those streams still ride on one TCP connection, and TCP promises to deliver bytes in order.

So if one packet is lost, TCP holds back everything that arrived after it until the lost packet is resent. It doesn't know or care that those later packets belong to a different image. Every stream on the connection stalls.

On a clean office network, you'd never notice. On mobile data or a busy Wi-Fi, packet loss is normal, and HTTP/2 over a single connection can sometimes perform worse than HTTP/1.1's several independent connections.

HTTP/3: QUIC over UDP

You can't change TCP's in-order behaviour, because TCP lives in operating systems and in every router and firewall between you and the server. So HTTP/3 runs on a newer transport, QUIC, built on top of UDP.

UDP itself is a "send it and hope" protocol. QUIC adds reliability, congestion control and encryption on top, but tracks each stream separately. A lost packet only delays the stream it belongs to. The other images keep loading.

QUIC brings a few other wins:

• Faster setup. TLS 1.3 is built into QUIC, so the transport and encryption handshakes happen together instead of one after the other. Returning visitors can even send data in the very first flight (0-RTT), with some replay caveats for non-idempotent requests.
• Connection migration. A TCP connection is tied to your IP address and port. Walk out of the office from Wi-Fi to mobile data and it breaks. QUIC uses connection IDs, so the connection can survive the switch.
• Always encrypted. There is no plain-text HTTP/3.

Header compression gets a QUIC-friendly version too, called QPACK, because HPACK assumed in-order delivery.

Side by side

So what do you actually need to do?

Here's the nice part: your Laravel controllers, React components and API routes don't change at all. HTTP/2 and HTTP/3 are negotiated between the browser and whatever terminates TLS: your web server, load balancer or CDN.

• Turn it on where TLS ends. Most CDNs and cloud load balancers support HTTP/2 by default and HTTP/3 as an option. Nginx, Apache and Caddy support HTTP/2; Caddy and recent Nginx versions also support HTTP/3.
• Open UDP 443. HTTP/3 needs UDP on port 443 through your firewall or security group. Browsers discover HTTP/3 through an Alt-Svc header on an earlier response and fall back to HTTP/2 quietly if UDP is blocked.
• Retire the old hacks carefully. Domain sharding now hurts, because it splits one efficient connection into several. Giant single bundles matter less, though fewer, well-split bundles are still good practice.
• Check what you're really getting. In Chrome DevTools, right-click the Network table headers and enable the "Protocol" column. You'll see http/1.1, h2 or h3 per request.

From the command line, curl -I --http2 https://example.com shows the protocol in the first response line. HTTP/3 needs a curl build with HTTP/3 support, so don't panic if --http3 isn't recognised.

The short version

• HTTP/1.1: one request at a time per connection, so browsers opened several connections and developers invented hacks.
• HTTP/2: many requests share one connection, with compressed headers, but one lost TCP packet stalls them all.
• HTTP/3: QUIC over UDP gives each stream independent delivery, faster handshakes and connections that survive network changes.
• Your application code stays the same. The work is in the server, CDN and firewall config.

If you open DevTools on your main project right now, which protocol do you see on your API calls: h2, h3, or (be honest) http/1.1?