From URL to first byte, and where it fails

Modules 1 through 6 gave you the individual pieces: layers, encapsulation, the two models, identifiers, and subnetting. This module connects them into a single end-to-end sequence. 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. 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 and a nearby server: roughly 45ms. Cold start with full DNS resolution and a distant server: 150 to 300ms.

The diagram below shows the five stages of a request path. Each stage depends on the one before it. If DNS fails, nothing after it can happen.

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.

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. The only thing still visible in plaintext is the SNI (Server Name Indication) in the ClientHello, which contains the hostname. Encrypted Client Hello (ECH) is being developed to fix that last gap.

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.

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).

As of 2025, HTTP/3 over QUIC carries over 25% of internet traffic. All major browsers support it. Google, Cloudflare, and Meta use it extensively.

The first request to a new server pays every cost upfront: DNS resolution (no cache), TCP handshake (new connection), TLS handshake (new session), and full HTTP response (nothing cached). On a 100ms link, that adds up to 300ms+ 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.

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.