System Design · Module 2 · Lesson 1 of 4 · 35 min
Client Server and the HTTP Request Journey
Follow one browser request through name resolution, connection setup, TLS and HTTP, and identify which stages can be reused.
01 The idea
The problem this lesson solves
When a browser opens https://example.com/guide, it does not send the URL to a single magical “internet” component. It discovers an address, establishes a protected connection, sends an HTTP operation and interprets a response. Each stage can fail independently. Following this journey gives you a practical way to reason about latency, proxies, timeouts and the difference between a reachable machine and a working application.
Use the requirements and ownership vocabulary from module 1. This module follows one request across the API boundary.
02 Worked example
Follow an HTTPS request from name to response
03 The method
Understand the mechanism
Parse the URL before sending anything
The scheme https selects protected HTTP communication. The hostname example.com identifies the origin name, and /guide is the path used by the application. A query string supplies additional request parameters. A fragment such as #examples is normally interpreted by the browser and is not part of the HTTP request target sent to the server.
The hostname is not necessarily the name of the machine that executes business logic. It may resolve to a CDN, reverse proxy or load balancer. That entry point can terminate the client connection and create another connection to an application. From the browser’s perspective, it is still communicating with the named origin under the protocol’s rules.
This distinction helps debug ownership. A certificate error can happen before the application sees a request. An HTTP error can be generated by an intermediary rather than your code. A successful DNS lookup establishes only that an address answer was obtained; it does not establish that the intended application is healthy.
Keep a layered trace: name lookup, transport connection, TLS, HTTP and application work. These are related stages, but their failure signals mean different things.
Resolve the name to an address
The browser or operating system may already have a usable cached answer. Otherwise, a resolver obtains an answer through DNS, potentially consulting other servers and following the domain’s delegation. The result can contain IPv4 or IPv6 addresses, or aliases that lead to address records.
Caching avoids repeating the full discovery work for every request. A record’s time to live influences how long a cached answer may be reused. It does not push a new address instantly into every client when an operator changes DNS. Existing caches and existing connections can continue to use an old destination for some time.
DNS answers may direct different clients to different entry points. A geographically nearby address can reduce network distance, but DNS-based routing cannot know the exact outcome of every later application request. Health-aware DNS also has the delay introduced by observation and caching.
For this lesson, treat resolution as producing an entry address. The later routing module explores authoritative servers, recursive resolvers, migration overlap and CDNs in more detail. The essential boundary is that the DNS resolver answers the naming question; it does not forward the browser’s HTTP request to the application.
Establish transport and TLS
For the TCP-based HTTPS path used here, the client establishes a TCP connection to the entry address. TCP supplies an ordered byte stream while the connection is functioning. It handles retransmission and ordering at that layer; it does not understand whether a business operation committed.
TLS then establishes encrypted communication and authenticates the server under the certificate and trust rules. The certificate must be valid for the requested hostname. Encryption protects communication in transit, but it does not decide whether the caller may edit link a7. That authorization belongs to the application.
Connection setup can require network exchanges before useful application data is returned. Reusing an established connection avoids repeating some setup work. Actual behavior depends on protocol versions, session resumption, intermediaries and client configuration. HTTP/3 uses QUIC rather than this TCP path, so do not memorize “all HTTPS uses TCP” as a universal rule.
A load balancer may terminate TLS and forward HTTP over a separately protected or otherwise controlled internal connection. That creates two transport relationships, not one end-to-end TCP connection. Make the trust boundary explicit when explaining which component can inspect headers or paths.
Read the HTTP message as a contract
In an HTTP/1.1-style textual representation, a request contains a method and target, header fields, and sometimes a body. GET /guide asks for a representation. Host identifies the intended host in that form of the protocol. Accept describes acceptable response formats. Authorization or cookies may carry credentials according to the application’s authentication scheme.
A response contains a status and headers, plus a body when the operation permits one. Content-Type describes the representation format. Cache-Control influences caching behavior. A redirect can identify another location with a Location header. A JSON body is data inside the HTTP message, not a replacement for HTTP semantics.
HTTP/2 and HTTP/3 encode messages differently on the wire, but the method, status and field concepts remain useful. Browser developer tools show a decoded view. Learn to read that view instead of assuming every protocol version transmits the same textual lines.
Headers can affect correctness. If a representation varies by language or authenticated user, an intermediary must not reuse an incompatible cached copy. If an app trusts a forwarded client identity header, it must know which trusted proxy sets or sanitizes that field. Otherwise a caller may supply a misleading value directly.
Follow the server’s work and the return path
The entry point routes the request to an eligible application instance. The app parses input, applies authentication and authorization where needed, invokes business logic and accesses storage. Each remote dependency adds another failure boundary and usually consumes a connection or in-flight work slot.
Suppose the app returns a redirect for a7. The browser receives a 3xx response with Location and may make a new request to that destination. Returning the redirect does not mean the short-link server fetched the destination page. A server-side preview fetcher would be a different feature with different security and capacity requirements.
The response can fail to reach the caller after the database work has finished. A closed connection or client timeout does not roll back a committed transaction. This is the reason the retry lesson distinguishes request attempts from logical operations.
Likewise, a response status alone may not explain the source of failure. A gateway timeout may mean an upstream deadline expired; the app may still be running. Correlate gateway logs, application traces and database observations using request identifiers, while avoiding sensitive payloads in routine logs.
Measure intervals without inventing precision
Use curl to observe headers and timing. Its time_namelookup, time_connect, time_starttransfer and time_total values are cumulative landmarks from the start of the operation, not independent durations to add. Their exact interpretation depends on connection reuse, redirects and the protocol path.
For a simple fresh TCP connection, time_connect minus time_namelookup approximates the post-DNS connection interval. time_starttransfer includes work before the first response byte, such as connection setup and server processing. It is not a pure database timer. time_total includes receiving the response body as well.
Repeated observations help separate one-time setup from steady-state behavior. A warm connection may be faster than a cold one; a cached DNS answer may avoid a lookup. A single fast request does not establish p99 latency, and a single slow request does not identify which dependency is responsible.
When diagnosing a slow page, first locate the delayed stage. Then inspect evidence at that boundary. Adding a database index cannot fix a certificate validation failure, and adding app instances cannot shorten geographic network distance. The journey gives you a map for choosing the next measurement.
Guided tutorial
Inspect a response
Run curl -I https://example.com. This uses HEAD to request response metadata without a normal response body. Identify the status, Content-Type if supplied, and cache-related fields. Exact headers can change. The task is to explain what each observed field tells a client, not to match a frozen screenshot.
Observe the timing landmarks
Run the timing command below several times. Copy one result and calculate connect minus dns. Do not add dns, connect, start and total: later values already include earlier intervals. Explain why start includes more than application execution.
Trace a redirect separately
In browser developer tools, inspect a known redirect or a local endpoint you control. Identify the original response and the next request as two exchanges. Note which host receives each request. Do not mistake a Location header for content downloaded by the redirect service.
Classify three failures
Write where you would investigate an unresolved hostname, an invalid TLS certificate and an HTTP 503. The first concerns naming, the second connection authentication, and the third a received HTTP failure response. Then add a client timeout after commit and explain why its business outcome is unknown without another protocol.
Shell commands
curl -I https://example.com
# Optional timing observation; values vary with your network:
curl -o /dev/null -s -w "dns=%{time_namelookup} connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n" https://example.com
# curl time_* values are cumulative from request start; do not sum them.
# For example, time_connect - time_namelookup approximates the
# post-DNS connection interval for the observed path.Check your result
The first command returns response headers. The timing command prints cumulative durations in seconds; subtract boundaries to estimate intervals rather than adding the reported values.
04 Cheat sheet
Review the decisions
Use this table to explain the mechanism and its limit without memorizing a product name.
| Choice or concept | Remember | Check |
|---|---|---|
| DNS | Find a record for the host | Caching and resolver path |
| TCP / QUIC | Transport connection | Loss and connection reuse |
| TLS | Protected authenticated channel | Certificate and handshake behavior |
| HTTP | Request and response semantics | Application and dependency work |
05 Where & why
Check the primary references
Use official references for protocol and implementation details. The questions here are teaching prompts.
06 Interview questions
Explain the reasoning out loud
Answer before opening the explanation. The questions progress from vocabulary to decisions and failure behavior.
What does DNS mean?
What does TLS mean?
What does Connection reuse mean?
Does DNS return the web page?
Does every HTTPS request create a new TCP connection?
What does TLS fail to solve?
Why can origin CPU be low while a page is slow?
Is time to first byte the same as total load time?
07 Practice problems
Practice a new case
Solve the new cases before revealing hints. Complete worked solutions follow the set.
Parse a URL
EasyShow the hint
Assign a protocol
EasyShow the hint
Cold timing
MediumShow the hint
Warm timing
MediumShow the hint
Find the bottleneck
MediumShow the hint
Draw both legs
HardShow the hint
Worked solutions
1. Parse a URL
Host is example.com, port is 8443 and path is /api/notes. The scheme is HTTPS.
2. Assign a protocol
DNS performs name lookup; TLS protects the connection; HTTP describes the GET and its response.
3. Cold timing
The modeled total is 150 ms. It does not include unmodeled response-body transfer or browser processing.
4. Warm timing
The modeled response wait remains 75 ms. Actual network and application costs still need measurement.
5. Find the bottleneck
Investigate server/proxy/dependency waiting and request queues. Increasing bandwidth is unlikely to remove a delay dominated by the response wait.
6. Draw both legs
The browser resolves and connects to the CDN; the CDN forwards over its own upstream connection. Distinguish client-to-edge timing, edge cache lookup, upstream connection behavior and origin processing.