From URL to first byte, and where it fails

The Foundations modules so far gave you the individual pieces: layers, encapsulation, the two models, identifiers, subnetting, the IPv6 address plan, and the Wi-Fi first hop. This module connects them into a single end-to-end sequence. The path below is the cold HTTPS-over-TCP case: no DNS cache entry, no open connection, and no resumable TLS session. When you type https://example.com and press Enter, here is what happens:

Step 1: DNS resolution. The browser needs an IP address. It checks its own cache, then the OS cache, then sends a recursive query to the configured resolver. The resolver walks the DNS hierarchy (root, TLD, authoritative) and returns an A or AAAA record. Typical time: 0ms (cached) to 100ms (cold lookup).

Step 2: TCP handshake.The browser opens a TCP connection to the server's IP on port 443. SYN, SYN-ACK, ACK: the three-way handshake costs one round trip. On a 20ms link, that costs 20ms. The 4-tuple (source IP:port, destination IP:port) now identifies this connection.

Step 3: TLS handshake. Over the TCP connection, the browser and server negotiate encryption using TLS 1.3 (RFC 8446). The browser sends a ClientHello with supported cipher suites and a key share. The server responds with its certificate and key exchange. One round trip. 20ms more.

Step 4: HTTP request. The browser sends GET / HTTP/1.1with headers including Host: example.com. With HTTP/2, this is a compressed HEADERS frame. The request travels encrypted inside the TLS session.

Step 5: Server processing. The server receives the request, runs its application logic (reading files, querying databases, executing code), and builds a response. This can take 1ms for a static page or 500ms+ for a complex dynamic page.

Step 6: HTTP response. The server sends back a status code (200 OK, 404 Not Found, 500 Internal Server Error) followed by response headers and the body content. The browser starts parsing HTML as it arrives, without waiting for the full response.

Total time to first byte (TTFB): DNS + TCP + TLS + server processing. With a warm cache, a reused connection, and a nearby server it can be tens of milliseconds. A cold start with full DNS resolution and a distant server often lands in the 150 to 300 ms range before application processing is counted.

The diagram below shows the cold request path. Each stage depends on the one before it for this TCP-based path. If DNS fails, nothing after it can happen; if the connection is already warm, several setup stages may be skipped.

That waterfall is still the right skeleton, but two of its steps have been rewritten since it was first taught. The DNS step now returns more than an address, and the connection step is no longer a single attempt to a single address over TCP.

Steps 1 and 2 describe a browser that asks DNS for one address and then opens TCP to it. A current browser usually does something more elaborate, and most of the extra work happens before any transport connection exists.

The lookup asks how to connect, not just where. Alongside A and AAAA, the browser may query the HTTPS record for the name (RFC 9460), a service binding record that publishes connection parameters. It can carry an ALPN list naming the protocols the endpoint speaks, address hints so the client needs no second lookup, an alternative target name or port, and the public keys for Encrypted Client Hello. A browser that reads h3 in that list can open HTTP/3 on the very first connection, instead of connecting over TCP and only learning that HTTP/3 exists from an Alt-Svc response header on a later request.

The client races the address families. When the name resolves to both an IPv6 and an IPv4 address, the browser does not pick one and wait for it to time out. Happy Eyeballs (RFC 8305) starts the IPv6 attempt, waits a short stagger (RFC 8305 recommends 250 milliseconds for the connection attempt delay), then starts the IPv4 attempt alongside it and keeps whichever connects first. Version 3 of the algorithm is still an Internet-Draft, so version 2 is the behaviour to reason about.

The transport is often not TCP. If the endpoint advertises h3, the browser can open QUIC on UDP port 443 (RFC 9000). QUIC carries the TLS 1.3 handshake inside its own setup, so steps 2 and 3 of the waterfall collapse into one exchange: there is no separate TCP handshake to watch and no separate TLS handshake after it.

The mental model changes with it. "Connect, then speak" becomes "ask DNS how to connect, then race". That is not decoration: it decides what you will see when you look.

Each of the three moves fails in its own way. A resolver or middlebox that mishandles the HTTPS query type returns nothing useful, so the browser falls back to plain A and AAAA records and pays for a second connection to reach HTTP/3. A firewall that drops UDP 443 makes every QUIC attempt fail, and the browser quietly retries over TCP, so the symptom is a slower start rather than an error. And an IPv6 path that black-holes traffic is absorbed by the race on a dual-stackclient, which is why "the site loads" is never evidence that IPv6 works.

None of this removes the old failure signatures. It moves them: a step that used to be one attempt to one address is now a race, and the losing attempt is usually invisible to the user. That is why the next section reads each step by the error it produces rather than by the order it runs in.

Each step produces a distinct error when it fails. Knowing which error maps to which step tells you where to focus your investigation.

DNS failure. The browser shows ERR_NAME_NOT_RESOLVED. You cannot reach the site by hostname, but you might be able to reach the server by IP address directly. Causes: DNS server down, domain expired, incorrect DNS record, network blocking port 53.

TCP timeout. The browser shows ERR_CONNECTION_TIMED_OUTafter a long wait (typically 20+ seconds). The SYN packet went out but no SYN-ACK came back. Causes: server down, firewall dropping packets to port 443, wrong IP address, network path broken.

TCP refused. The browser shows ERR_CONNECTION_REFUSEDimmediately. The server is reachable but nothing is listening on port 443. The server sent a TCP RST (reset) packet. Causes: web server not running, service crashed, listening on a different port.

TLS failure. The browser shows a certificate warning orERR_CERT_COMMON_NAME_INVALID. TCP connected successfully, but the TLS handshake failed. Causes: expired certificate (like the Sectigo incident), hostname mismatch, unsupported TLS version, untrusted certificate authority.

HTTP error. The connection succeeded. TLS completed. But the server returned an error status code. 500 means the server crashed internally. 502 means a reverse proxy could not reach the upstream application. 503 means the server is overloaded. 403 means you are authenticated but not authorised for this resource.

Of those five signatures, the TLS one is the only failure that proves the layers beneath it are healthy: the name resolved, the connection opened, and the rejection came from certificate checking. That makes the handshake itself worth reading closely.

TLS 1.3 (RFC 8446, published August 2018) reduced the handshake from 2 round trips (TLS 1.2) to 1 round trip. It also removed several insecure features that had been exploited in attacks against TLS 1.2.

In TLS 1.2, the server's certificate was sent in plaintext. Anyone on the network could see which website you were connecting to by reading the certificate. TLS 1.3 encrypts the certificate, improving privacy. In many deployments, the SNI (Server Name Indication) value in the ClientHello still reveals the hostname. Encrypted Client Hello, standardised in RFC 9849, can hide the real ClientHello and SNI when the client, DNS records, and server infrastructure support it.

TLS 1.3 also mandates forward secrecy. Every connection uses a fresh key exchange (Diffie-Hellman). If a server's long-term private key is compromised later, previously recorded traffic cannot be decrypted. TLS 1.2 allowed RSA key exchange, which did not provide forward secrecy.

Forward secrecy and the one round trip handshake settle how the encrypted channel is built. What travels inside it is decided by the HTTP version, and each generation of HTTP was written to remove a different bottleneck in that channel.

HTTP/1.1 (RFC 9112) sends requests as plain text, one at a time per connection. Browsers open 6 to 8 parallel connections to the same server to work around this limitation. Connection reuse (keep-alive) is the default, which avoids repeating the TCP and TLS handshakes for every request.

HTTP/2 (RFC 9113) uses binary framing and multiplexes many requests over a single TCP connection using streams. Headers are compressed with HPACK, reducing redundant data. The downside: a single lost TCP packet blocks all streams because TCP guarantees in-order delivery. This is called head-of-line blocking.

HTTP/3 (RFC 9114) replaces TCP with QUIC (RFC 9000), a UDP-based transport that integrates TLS 1.3 encryption. Each QUIC stream is independently ordered, so a lost packet on one stream does not block the others. QUIC also supports connection migration: if your phone switches from Wi-Fi to cellular, the QUIC connection survives (identified by a Connection ID, not the IP 4-tuple).

All major browsers support HTTP/3, and large CDNs and internet platforms deploy it widely. The operational point is not a single traffic percentage; it is that modern request diagnosis must recognise both HTTPS over TCP and HTTP/3 over QUIC paths.

Parallel connections, multiplexed streams and independent stream ordering all make the second and later requests cheaper. None of them removes the setup the very first request has to pay for, which is where the whole waterfall becomes visible at once.

A cold request to a new server usually pays every setup cost upfront: DNS resolution with no cache, TCP handshake on a new connection, TLS handshake with no session ticket, and a full HTTP response with no cached object. On a 100 ms round-trip path, those setup costs can add hundreds of milliseconds before a single byte of content arrives.

Subsequent requests benefit from caching at every layer. DNS answers are cached (per the TTL). The TCP connection stays open (keep-alive). TLS sessions can be resumed in 0-RTT with TLS 1.3. HTTP responses are cached if the server sends appropriate Cache-Control headers.

The word "usually" matters. The connection dance in section 7.2 already removes part of that bill: a pooled HTTP/3 connection skips setup entirely, an HTTPS record can save a wasted first connection over the wrong protocol, and a browser that preconnects starts the lookup and the race before the user clicks anything. The fundamentals do not change; what changes is which part of the setup path the user pays for at the moment of the click.

CDNs (Content Delivery Networks) like Cloudflare, Akamai, and AWS CloudFront reduce first-request latency by serving content from edge servers near the user. Instead of a 100ms round trip to a distant origin, the CDN edge might be 5-10ms away. The CDN also terminates TLS at the edge, so the handshake completes quickly even if the origin server is far away.