The browser's got the server's IP. The stage is set. (Read Part 1 to see how we got here)
But before any data can take the spotlight, there's a quiet negotiation behind the curtain, transport protocols must sync, encryption must lock in, and the browser and server must agree on the version of HTTP they'll use to communicate.
And hence, the overture begins: TCP, QUIC, and TLS aligning rhythm and rules before the first note of data is exchanged.
Let's listen in on this silent symphony between knowing where to go and finally saying hello.
- Connecting Fast and Secure: QUIC, TCP, and TLS
- Faster connection setup: QUIC combines transport and encryption handshakes into a single round trip, compared to two round trips in case of TCP. Instead of saying, "Let's connect,” then “Let's encrypt," QUIC says both at once.
- Independent streams: One stalled stream won't block others, unlike TCP's head-of-line blocking.
- Easier to evolve: QUIC runs in user space, meaning updates don't require OS changes.
- Built-in encryption: TLS 1.3 is integrated directly into QUIC.
- Encrypted handshake: The handshake is encrypted, which helps avoid issues with firewalls and proxies expecting legacy TCP traffic.
-
By returning an HTTP response header:
Alt-Svc: h3=":443"; ma=2592000That's server-speak for: "I support HTTP/3 on port 443. Cache that info for 30 days."
-
Or by including a DNS record (SVCB or HTTPS) that signals HTTP/3 support.
- HTTP/1.1 opens multiple TCP connections to load assets in parallel.
- HTTP/2 improves on this with multiplexing over one connection but still suffers from TCP's single-stream design.
- The HTTP Games: Request and Response
With the IP address resolved, the browser now attempts to establish a connection.
If it knows the server supports HTTP/3, it uses QUIC, a UDP based transport protocol designed for speed and resilience.
If not, it falls back to HTTP/2 or HTTP/1.1, both of which run over TCP.
QUIC: Why Browsers Prefer It
Compared to TCP, QUIC offers several practical benefits:
By integrating core features like TLS and multiplexing, QUIC avoids the performance and layering issues baked into the TCP stack. It connects faster, handles packet loss better, and evolves quicker all while staying secure and private.
How the Browser Knows to Use QUIC
QUIC isn't assumed by default. The server must explicitly advertise support in one of two ways:
If HTTP/3 Fails
If HTTP/3 isn't supported or fails, the browser falls back to TCP.
A single lost packet in HTTP/2 can delay all active streams. QUIC avoids this by isolating streams, so other data keeps flowing even if one stream hits a hiccup.
With transport and encryption ready, the browser sends its first HTTP request, usually a GET / asking for the root HTML.
In HTTP/1.1, this is plain text:
GET / HTTP/1.1
Host: sahilten.com
User-Agent: …
Accept: text/html
In HTTP/2 and HTTP/3, it's framed as binary.
The server processes the request and replies with an HTTP response:
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 14750
...
<html></html>
The time from request to first byte is Time to First Byte (TTFB). It's a key performance metric that captures server speed and network latency.
This HTML response kicks off a second wave of browser activity. The browser begins turning HTML into pixels, parsing, layout, paint, and render happens in the next stage.
This entire process is incremental and streaming: the page starts rendering as soon as enough data is available, often before the full HTML has arrived.
Meanwhile, the browser is sending additional HTTP requests for resources like CSS files, JS files, fonts, images etc.
These requests are prioritized based on type and placement in the HTML, and protocols like HTTP/2 and HTTP/3 help by sending them concurrently over a single connection. Service workers, memory cache, and disk cache may intercept or fulfill some of them (as we discussed earlier), reducing latency or avoiding the network entirely.
The goal is to get to First Contentful Paint (FCP) and then Largest Contentful Paint (LCP) as quickly as possible, marking visible progress for the user.
Wrap-up
The connection's done and the data's flowing.
Next up, we'll see how the browser takes that stream of HTML and transforms it into something visual. From parsing and layout to painting and compositing, we'll break down how raw markup becomes real pixels on your screen. Stay tuned!