Client Server and the HTTP Request Journey

01 The idea

The problem this lesson solves

The browser obtains an address, possibly from a local or recursive DNS cache.

Prerequisite: earlier lessons introduce the vocabulary and shared examples used here. Follow the module order.

02 Worked example

Follow one worked example

Trace the example in order. Follow the same identities, units and state transitions through the diagram and the events below.

Measure the request as a sequence of stages; a slow page does not by itself identify a slow application server.

03 The method

Mechanisms decisions and a guided tutorial

Work through the explanation in order, then apply it in the tutorial. Each comparison names a cost as well as a benefit.

The journey before the application sees a request

DNS resolves a hostname to an address, usually through caches and a recursive resolver. A typical HTTPS connection over TCP then establishes TCP and TLS before sending HTTP data. Existing connections can be reused, and HTTP/3 uses QUIC over UDP instead, so do not claim every request always performs all these steps. DNS locates the service; TLS authenticates the server and encrypts transport; HTTP describes the operation. A slow page can be slow at any of these stages.

One address, several boundaries

A URL contains a scheme, host and path. For https://example.com/guide, the browser needs an address for example.com, a secure connection to the intended server, and an HTTP request for /guide. DNS answers the naming question; it does not send the HTTP page. TLS protects the connection; it does not decide which user may edit a document.

A proxy or CDN may terminate the browser connection and start another upstream connection. Record which machine each timing belongs to. An idle origin can coexist with a slow client path, and a fast connection setup can coexist with a slow database query after the request arrives.

Read a timing waterfall

Assume a cold teaching request needs 20 ms for DNS, 40 ms for TCP, 40 ms for TLS and 60 ms for application processing plus the modeled response wait. The serialized total is 160 ms. A later request on the same connection may avoid the first three stages and pay roughly the modeled 60 ms. These are assumptions, not universal timing numbers.

Real browsers overlap some work, reuse connections, resume TLS sessions and may use HTTP/3 over QUIC. Use developer tools to see what actually happened. Compare cold and warm requests without claiming that every page load always repeats DNS, TCP and a complete TLS handshake.

Debug from observations

Start with the observed symptom and separate name-resolution delay, connection failure, certificate failure, time waiting for the response and body transfer. A large response can download slowly after the server has already produced it. A response can also be small but wait behind a slow dependency.

Keep the HTTP contract independent of the transport lifecycle. An established TCP connection does not mean the next HTTP operation will succeed. The server can receive and commit a write while the connection later breaks, which is the retry ambiguity studied in a later lesson.

Guided tutorial

1. Inspect a URL

Separate scheme, hostname, port and path for two example URLs.

2. Record a cold request

Use browser Network tools with a new connection and identify timing stages.

3. Compare a repeat

Reload or issue a second request and note which stages disappear or shrink.

4. Write a diagnosis

Explain one case where the browser is slow while origin CPU remains low.

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.

04 Cheat sheet

Review the decisions

Use this table to explain the mechanism and its limit without memorizing a product name.

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.

07 Practice problems

Practice a new case

Solve the new cases before revealing hints. Complete worked solutions follow the set.

Worked solutions