A comprehensive walk through the full request lifecycle: DNS resolution, TCP/TLS handshake, HTTP request, CDN routing, origin processing, WebSocket upgrade, and everything in between.
Every time you type a URL into a browser and press Enter, a remarkably complex chain of protocols fires in sequence: DNS resolution, TCP or QUIC connection, TLS handshake, HTTP request routing, CDN processing, and finally browser rendering. Understanding this full lifecycle — and how each layer can fail — is the foundation of web performance tuning and network debugging.
When you enter https://example.com/page in a browser address bar and press Enter, the following sequence occurs:
1. URL parsing and input normalisation. The browser parses the URL into scheme (https), host (example.com), port (implied 443), and path (/page). It checks for HSTS preload lists, applies URL formatting rules, and determines whether the input is a search query or a URL.
2. DNS lookup. The browser checks its local DNS cache, then the OS cache, then the configured recursive resolver (often your ISP or a public resolver like 1.1.1.1 or 8.8.8.8). If no cached record exists, the resolver queries the root nameservers, which delegate to the TLD servers (e.g., .com), which delegate to the authoritative nameservers for example.com. The final A or AAAA record is returned and cached according to its TTL.
3. Transport connection. For HTTP/1.1 and HTTP/2, the browser opens a TCP connection to the resolved IP address on port 443. This is a three-way handshake: SYN, SYN-ACK, ACK. For HTTP/3, the browser establishes a QUIC connection over UDP instead, which combines the transport and cryptographic handshakes into a single round trip (or zero round trips for returning clients).
4. TLS handshake. Over the TCP or QUIC connection, the browser and server perform a TLS handshake. The server presents its X.509 certificate, which the browser validates against a trusted root CA store. The two sides agree on a cipher suite and exchange key material (typically via ECDHE) to derive session keys. On a QUIC connection, this happens as part of the transport handshake — one fewer round trip.
TLS 1.3 Handshake (simplified):
ClientHello ──────────────────────>
<────────────────── ServerHello + Certificate
<────────────────── ServerFinished
ClientFinished ──────────────────────>
[Encrypted Application Data begins]5. HTTP request. With the encrypted channel established, the browser sends the HTTP request. In HTTP/1.1, each request consumes the connection until the response completes (though multiple connections can be pooled). In HTTP/2, the request is broken into binary frames and multiplexed over the single connection alongside other requests. In HTTP/3, the same multiplexing happens over QUIC streams, eliminating the risk of one lost packet blocking all streams.
6. CDN routing and caching. If the domain is behind a CDN (Cloudflare, Fastly, Akamai, etc.), DNS resolves to a CDN edge server rather than the origin. The edge server checks its cache: if the resource is cached and fresh (within max-age), it returns the cached copy — a cache HIT. If not, it fetches from the origin, caches the response, and forwards it — a cache MISS. CDNs also handle Cache-Control, ETag, and Vary headers to determine cacheability.
7. Origin processing. The origin server receives the request, processes it (runs application logic, queries a database, renders a template), and generates a response. This is often the slowest part of the lifecycle — measured as Time To First Byte (TTFB). A high TTFB typically indicates backend bottlenecks: slow database queries, inadequate caching, or CPU-bound application code.
8. Response delivery and browser rendering. The response travels back through the network layers. The browser receives the response headers first (status code, Content-Type, CORS headers, cache directives), then the body. If the response is HTML, the browser parses it, builds the DOM, discovers subresources (CSS, JS, images), and issues additional requests for each. CSS blocks rendering, JavaScript blocks parsing unless async or defer is specified. CORS checks happen at this stage: if a cross-origin resource lacks the right Access-Control-Allow-Origin header, the browser blocks the response from script access.
Each layer in this lifecycle can fail, and knowing how to diagnose failures is critical:
dig +trace example.com or nslookup to see where the chain breaks.Connection reset error indicates the server actively refused the connection — often a firewall rule, a misconfigured load balancer, or a rate limit being hit.openssl s_client -connect example.com:443 to inspect the certificate chain and expiry date.Access-Control-Allow-Origin response header.curl -w '@#connect:%{time_connect} @#ttfb:%{time_starttransfer}' to isolate network from backend latency.# Diagnose each protocol layer with curl -v
$ curl -v https://example.com/page
* Trying 93.184.216.34:443...
* TCP_NODELAY set
* Connected to example.com (93.184.216.34) port 443 (#0) # TCP done
* ALPN, offering h2,http/1.1
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305 # TLS done
* ALPN, server accepted to use h2 # HTTP/2
> GET /page HTTP/2
> Host: example.com
> :path: /page
> :scheme: https # HTTP request sent
< HTTP/2 200
< content-type: text/html
< cache-control: max-age=600 # Response received
* Connection #0 to host example.com left intactThe simulator below lets you trace the entire request lifecycle from URL entry to rendered page. Select an HTTP version, toggle network conditions, and inspect each protocol layer's contribution to total page load time.
Real-world page load times are dominated by the sum of all protocol layers. A typical HTTPS connection over HTTP/1.1 involves: DNS (~20ms), TCP handshake (~30ms), TLS handshake (~50ms), and then a request-response cycle for each resource. On a slow connection (3G, 400ms RTT), that same sequence takes over a second before any data is received. This is why HTTP/2 multiplexing and HTTP/3's 0-RTT handshake matter enormously for mobile users.
CDNs optimise the routing layer by placing edge servers close to users, reducing DNS time (authoritative DNS at the edge) and eliminating round trips to a distant origin. When combined with HTTP/3, a page that might take 3-4 seconds to load on 3G over HTTP/1.1 can load in under a second — a difference that directly affects user engagement, conversion rates, and Core Web Vitals scores.
For DNS, configure short TTLs on records you might need to change quickly, use multiple DNS providers for redundancy, and monitor resolution times. For TLS, use automated certificate management (Let's Encrypt with certbot or ACME), pin to TLS 1.3 where possible, and configure a strong cipher suite. Monitor certificate expiry with alerts.
For HTTP, enable CDN caching aggressively for static assets, configure correct Cache-Control and ETag headers, and use HTTP/2 or HTTP/3 multiplexing to avoid connection overhead. For CORS, maintain a strict allowlist of origins, never reflect the Origin header, and set Vary: Origin on cacheable responses. For backend performance, instrument TTFB monitoring, add database query caching, and consider edge computing to move processing closer to the user.
curl -v, dig +trace, openssl s_client, and browser DevTools to isolate which layer is causing a problem.1.In what order do the protocol layers execute during a typical HTTPS page load?
2.What tool would you use to determine whether high TTFB is caused by network latency or a slow backend?
3.How does HTTP/3 improve over HTTP/2 for mobile users?