What is the HTTP Request Lifecycle?
The HTTP request lifecycle explained — DNS, TCP/TLS handshakes, request/response, and rendering — with examples and interview Q&A.
Expected Interview Answer
The HTTP request lifecycle is the full sequence a browser follows to load a resource: DNS resolution, TCP (and TLS) connection setup, sending the HTTP request, the server processing it and sending a response, and finally the browser rendering or using that response.
It starts with DNS resolution, translating the hostname into an IP address, often cached at multiple levels to speed this up. Next the browser opens a TCP connection via the three-way handshake, and for HTTPS layers a TLS handshake on top to negotiate encryption. The browser then sends the HTTP request line, headers, and optional body; the server routes it, runs application logic, may query a database, and returns a status line, headers, and a response body. The browser reads the response, may cache it per the Cache-Control headers, and either renders it or hands it to JavaScript — and for pages with many resources, this cycle repeats per resource, which is why connection reuse (keep-alive) and multiplexing (HTTP/2) matter so much for real-world performance.
- Clarifies where latency comes from (DNS, handshake, TLS, server, render)
- Explains why connection reuse and multiplexing improve performance
- Helps debug slow-loading pages by isolating each stage
- Grounds caching headers in a concrete request flow
AI Mentor Explanation
Sending an HTTP request is like a captain first checking the fixtures board to find which ground a match is at (DNS), then travelling there and shaking hands with the opposing captain to agree on rules (TCP/TLS handshake). Only after that does the actual over get bowled — the request — and the response is the outcome relayed back, which the scoreboard then displays (rendering). If the same ground hosts the next match too, the teams skip the travel and handshake and go straight to play (connection reuse).
Step-by-Step Explanation
Step 1
DNS resolution
The hostname is resolved to an IP address, often via cached resolvers.
Step 2
Connection setup
TCP three-way handshake, plus TLS handshake for HTTPS.
Step 3
Request/response
The browser sends the HTTP request; the server processes and responds.
Step 4
Render/reuse
The browser renders or uses the response, reusing the connection for further requests.
What Interviewer Expects
- All major stages named in the correct order
- Distinguishing TCP handshake from TLS handshake
- Understanding why connection reuse and HTTP/2 matter for performance
- Awareness that caching can short-circuit parts of the lifecycle
Common Mistakes
- Skipping DNS resolution as a step
- Conflating the TCP handshake with the TLS handshake
- Assuming every request opens a brand-new connection
- Forgetting that caching can avoid a full round trip entirely
Best Answer (HR Friendly)
“When you load a webpage, your browser first looks up the site’s address, opens a secure connection, sends a request for the page, waits for the server to send back the content, and then displays it — and for pages with many parts, it repeats or reuses that process efficiently so everything loads quickly.”
Code Example
curl -w "\nDNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \
-o /dev/null -s https://example.comFollow-up Questions
- What happens during the TLS handshake specifically?
- How does DNS caching reduce lookup time on repeat visits?
- What is Time to First Byte (TTFB) and what affects it?
- How does keep-alive avoid repeating the connection setup steps?
MCQ Practice
1. What is the first stage of the HTTP request lifecycle?
The hostname must first be resolved to an IP address via DNS before any connection can be made.
2. Which handshake is unique to HTTPS and not present in plain HTTP?
TLS handshake negotiates encryption and is layered on top of the TCP handshake only for HTTPS.
3. What allows subsequent requests to skip connection setup entirely?
Keep-alive lets a browser reuse an already-open TCP/TLS connection for further requests.
Flash Cards
HTTP request lifecycle in one line? — DNS resolution, connection setup, request/response, then render or reuse.
What comes right after DNS resolution? — TCP three-way handshake, then TLS handshake if HTTPS.
What speeds up repeat requests to the same host? — Connection reuse via keep-alive, avoiding a new handshake each time.
What metric measures server response speed in this lifecycle? — Time to First Byte (TTFB).