Networks and HTTP: follow a request end to end
Separate protocol semantics, transfer time, round trips, and deadlines in a realistic request journey.
On this page
The question for today
What you’ll understand
- Explain the roles of DNS, transport, TLS, and HTTP.
- Estimate a transfer lower bound without confusing bandwidth with latency.
- Reason about deadlines and the ambiguity of a timeout.
Clicking a button can trigger name resolution, connection establishment, encrypted transport, application processing, and response transfer. A single reported duration hides those stages. Understanding them makes network debugging less mysterious: ask where time is spent, what each protocol promises, and what the client actually knows when a request succeeds, fails, or times out.
Different layers answer different questions
DNS helps resolve a host name to connection information. A transport carries data between endpoints, while TLS authenticates peers according to its configuration and protects communication in transit. HTTP defines application-level request and response semantics. Protocol versions use different transport mechanisms: do not assume every HTTP request uses the same connection behavior. A successful connection also does not prove that an application returned the right result.
An HTTP request includes a method and target, with fields and sometimes content. Its response includes a status and possibly content. Methods have defined semantics: a read-oriented operation and a state-changing operation are not interchangeable merely because both can carry JSON. Caches, proxies, clients, and servers rely on those semantics. Design and debug the complete exchange, including response codes, cache behavior, and error bodies.
Bandwidth and latency are separate constraints
Bandwidth describes how much data can pass per unit time. Latency describes delay, and a round-trip time measures a signal's journey to an endpoint and back. A small request can be dominated by round trips even on a high-bandwidth link. A large response can be dominated by payload transfer. Increasing bandwidth therefore helps some requests much more than others; locate the dominant term before choosing an optimization.
A connection can be reused, so setup costs need not be paid on every request. Conversely, name resolution, connection establishment, retries, and intermediary work may add delays that a simplistic payload calculation misses. Averages hide outliers. Record relevant timing stages where the platform exposes them, and compare distributions for representative locations and request sizes rather than treating a single local measurement as the user experience.
A timeout is incomplete knowledge
When a client stops waiting, the server may still be processing the operation or may already have completed it. A timeout therefore does not automatically mean that nothing happened. Retrying a state-changing request without an application-level duplicate policy can repeat an effect. Bound retry attempts, consider deadlines across downstream calls, and preserve enough request identity to investigate ambiguous outcomes without exposing sensitive payloads.
The queue lab isolates one contributor to request delay: waiting for service. Change arrival rate and service rate, then inspect the fluid backlog, initially four jobs. Its separate M/M/1 mean assumes Poisson arrivals, exponential service, one server, and arrivals slower than service. Neither calculation models DNS, TLS, or HTTP transport. Ask how a client deadline interacts with waiting before server work even begins.
Work it through
Why a small response is still slow
Use a simplified established-connection model with two effective round trips of 40 milliseconds, 30 milliseconds of server work, and a 250,000-byte payload over 20 million bits per second.
Convert the payload: 250,000 bytes contain 2,000,000 bits. At the stated rate, ideal transfer time is 0.1 seconds, or 100 milliseconds.
Add the modeled round-trip cost: two times 40 gives 80 milliseconds. Adding 30 milliseconds of server work yields an approximate 210-millisecond budget.
Doubling bandwidth lowers only the transfer term to 50 milliseconds, producing 160 milliseconds in this model. It leaves round-trip and server terms unchanged, so total latency does not halve.
Optimize the term that dominates the measured request. This additive budget is a teaching approximation; real stages can overlap or incur extra delays.
The living notebook
Explore the model
Interactive lab · queue
Waiting is part of request latency
Change arrival rate λ and service rate μ in max(0,4+(λ−μ)t). Inspect backlog growth separately from the displayed stable M/M/1 mean, which has additional stochastic assumptions. This lab does not simulate HTTP or network packets.
- Fluid backlog
- 4
- Net rate · λ − μ
- −1 /s
- M/M/1 mean residence
- 1 s
Fluid backlog starts at 4 and follows max(0, 4 + (λ − μ)t). The separate M/M/1 residence-time formula assumes Poisson arrivals, exponential service and λ < μ. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forEven a fast link cannot remove waiting caused by inadequate service capacity.
Pause & reason
Check your understanding
Your turn
Try it yourself
Ignoring all other costs, how long must 5 MB take over a 100 Mb/s bottleneck? Use decimal units.
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
Convert megabytes to megabits before dividing by the link rate.
Compare with the solution
Five million bytes are 40 million bits. Dividing by 100 million bits per second gives 0.4 seconds. This is an ideal lower bound; setup, protocol overhead, loss, congestion, and processing can only make the simplistic estimate inadequate as an exact prediction.
Keep the idea
Take it with you
- HTTP semantics are distinct from the transport carrying messages.
- Bandwidth improvements cannot remove round-trip or server costs.
- Timeouts create ambiguity that application contracts must handle.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.