From URL to first byte, and where it fails
By the end of this module you will be able to:
- Trace a web request from URL to first byte, naming each step in order
- Identify where a request can fail (DNS, TCP, TLS, HTTP) and what each failure looks like
- Explain why a cold request to a new server usually pays extra setup latency, and what warm paths skip
Real-world incident · May 30, 2020
One expired certificate broke thousands of websites overnight.
On May 30, 2020, the Sectigo AddTrust External CA Root certificate expired. This root certificate had been cross-signed to provide backward compatibility with older devices. When it expired, TLS handshakes started failing for websites that included it in their certificate chain.
The web servers were running. DNS was resolving. TCP connections succeeded. But when browsers tried to verify the server's TLS certificate, they hit the expired root and rejected the connection. Newer browsers handled it gracefully (they had a newer root). Older clients, embedded devices, and certain server-side HTTP libraries failed hard.
To diagnose this, you needed to know exactly where in the request sequence the failure occurred. That is what this module teaches: the complete chain from URL to first byte, and what breaks at each link.
DNS resolved fine. TCP connected fine. But TLS failed. How do you narrow it down to the right step?
7.1 The request sequence, step by step
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. 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. 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.
URL to first byte is a timed chain
DNS, transport setup, TLS or QUIC setup, HTTP request, server work, and first byte each leave different evidence.
First byte is the sum of DNS plus TCP plus TLS plus HTTP request plus server work. Each step is observable and each has its own failure signature.
Knowing the happy path is only useful when something goes wrong. Each step has a characteristic failure signature you can read immediately.
7.2 What failure looks like at each step
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.
Each request failure has a first useful test
Timeout, refused, NXDOMAIN, SERVFAIL, certificate failure, HTTP error, and high TTFB point at different boundaries.
Each observed failure points first at one boundary. Run the safe test for that boundary before guessing.
TLS failures deserve closer attention because TLS 1.3 changed the handshake significantly, and the version your client and server negotiate directly affects both latency and security posture.
7.3 TLS 1.3: what changed and why it matters
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.
“TLS 1.3 is a major revision to TLS which aims to address threats that have arisen over time.”
RFC 8446 - Section 1, Introduction
TLS 1.3 removed RSA key transport, CBC mode ciphers, RC4, SHA-1, compression, and renegotiation. Only five AEAD cipher suites are permitted, all with forward secrecy. This eliminated entire classes of attacks (BEAST, POODLE, CRIME, Lucky 13) by removing the features those attacks exploited.
With TLS established, HTTP determines how that encrypted channel is used. The version matters because each generation addressed a different performance bottleneck.
7.4 HTTP/1.1, HTTP/2, and HTTP/3
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.
Understanding the HTTP versions gives context for where latency comes from. The first request is where all of that latency is most visible because no caching has happened yet.
7.5 Why cold requests usually feel slower
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. Browsers can preconnect before the user clicks, reuse pooled HTTP/2 or HTTP/3 connections, race IPv6 and IPv4 connection attempts using Happy Eyeballs, and use HTTPS DNS records to learn connection parameters before opening a transport connection. These optimisations do not remove the fundamentals; they change which parts 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.
Common misconception
“A slow website means the server is slow.”
Time to first byte (TTFB) includes DNS, TCP, TLS, and server processing. A 300ms TTFB does not mean the server took 300ms. It might mean DNS took 80ms, TCP took 50ms, TLS took 50ms, and the server only needed 20ms. Measuring each step separately tells you where the time actually goes.
A user sees ERR_CONNECTION_TIMED_OUT in their browser. Which step in the request sequence failed?
You can reach a website by IP address but not by hostname. Where is the failure?
TLS 1.3 reduced the handshake from 2 round trips to 1. Why does this matter?
HTTP/2 multiplexes many requests over one TCP connection. Why does HTTP/3 use QUIC instead of TCP?
Core distinctions
- A cold HTTPS-over-TCP request follows DNS, TCP, TLS, then HTTP. Warm connections, HTTP/3, preconnect, and resumption can skip or combine parts of that setup path.
- Each step produces a distinct error when it fails. ERR_NAME_NOT_RESOLVED = DNS. ERR_CONNECTION_TIMED_OUT = TCP. Certificate warning = TLS. 500/502/503 = HTTP/server.
- Cold requests are usually slower because DNS, transport setup, TLS, and HTTP cache state are not warm yet. Subsequent requests reuse cached answers, pooled connections, TLS tickets, and cached responses.
- TLS 1.3 halved the handshake latency and removed insecure features. HTTP/3 over QUIC eliminated head-of-line blocking and added connection migration.
Standards and sources cited in this module
RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3
Section 2, Protocol Overview
Defines the 1-RTT handshake, mandatory forward secrecy, and 0-RTT resumption. Referenced in Section 7.3.
Section 15, Status Codes
Defines HTTP status codes (200, 403, 404, 500, 502, 503). Referenced in Sections 7.1 and 7.2.
Section 5, Streams and Multiplexing
Defines HTTP/2 binary framing and stream multiplexing. Referenced in Section 7.4.
Full specification
Defines HTTP/3 over QUIC, eliminating TCP head-of-line blocking. Referenced in Section 7.4.
RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport
Section 2, Streams
Defines independent stream ordering and connection migration. Referenced in Section 7.4.
RFC 9849, TLS Encrypted Client Hello
Abstract and protocol overview
Defines ECH, which changes the assumption that SNI is always visible during TLS setup. Referenced in Section 7.3.
RFC 8305, Happy Eyeballs Version 2
Section 1, Introduction
Defines the connection racing behaviour browsers and clients use to reduce delay across IPv6 and IPv4 paths. Referenced in Section 7.5.
RFC 9460, Service Binding and Parameter Specification via the DNS
Abstract and Section 1
Defines SVCB and HTTPS DNS records that can publish connection parameters before transport setup. Referenced in Section 7.5.
Sectigo AddTrust Root Certificate Expiry, May 30, 2020
Industry incident analysis
Real-world TLS failure caused by an expired root CA certificate. Used as the opening case study.
CompTIA Network+ N10-009 Exam Objectives
Domain 5.0, Network Troubleshooting (24% of exam)
Tests systematic troubleshooting across OSI layers, including request path diagnosis.
You have traced the complete request path. Module 8, the Foundations capstone, puts it all together into one practical skill: writing a four-part diagnosis note that tells a colleague exactly where to look and what to check next.
Module 7 of 21 in Foundations