Networking Essentials

Before a request reaches your application, several separate conversations may occur. DNS discovers an address; a transport carries bytes; TLS protects the connection; HTTP gives the exchange application meaning. Treating these as one step hides latency and failure boundaries. The practical goal is to explain where a request can wait, where it can be retried, and which component knows whether an operation actually happened.

Learning goals

DNS lookup versus request routing; IP; TCP and QUIC; TLS; HTTP connection reuse; timeouts; proxies; L4/L7 balancing; CDN cache behavior; SSE versus WebSocket.

The mechanism at a glance

Figure — Browser → DNS resolver (resolve name); Browser → Edge / CDN (HTTPS request); Edge / CDN → API origin (cache miss); API origin → Database (query); Private cache rules → Edge / CDN (constrain caching)

The numbered components identify responsibilities. Follow the labeled arrows rather than treating the numbers as a global execution order. The scenario later in this lesson shows one concrete sequence.

Step-by-step reasoning

1. Resolve a name

A browser usually consults cached DNS information or a recursive resolver to obtain an address. The resolver may consult authoritative DNS servers if needed. After resolution, ordinary application requests go to the resolved destination, not through the authoritative DNS server. DNS TTL affects how long an answer may be reused; it is not a precise traffic-switch timer for every client.

2. Establish a protected transport

HTTP/1.1 and HTTP/2 commonly run over TCP with TLS for HTTPS. HTTP/3 uses QUIC over UDP and integrates TLS. Connection setup and geographic round trips can dominate a small response, so reuse matters. TCP supplies an ordered byte stream; it does not tell your application that a purchase committed. TLS protects data in transit but does not replace authorization.

3. Route at the correct layer

A layer-four balancer routes connections using transport information. A layer-seven proxy understands HTTP attributes such as host and path and can send /images and /api to different origins. A CDN can answer eligible cache hits at the edge. Private, user-specific responses require careful cache keys and policies; a fast shared cache is harmful if it leaks another user’s data.

4. Budget timeouts and retries

Give the full request a deadline and allocate smaller budgets to dependencies. Otherwise three independent two-second waits may exceed the user’s total budget. Retry only when the operation’s contract permits it, with a bounded count and jitter. For continuous updates choose polling, SSE, or WebSockets according to directionality and recovery needs, not merely the word real-time.

Contracts and state

The following sketch makes the decision boundary concrete. Field names and capacity assumptions are illustrative; adapt them to the stated product contract.

Illustrative 400 ms request budget
Client -> edge: 60 ms
Edge -> API: 40 ms
API work and database: 220 ms
Return path + margin: 80 ms
All numbers are assumptions, not Internet constants.

Worked example

A dashboard shell loads quickly from a CDN but its API calls take two seconds. DNS is already cached and the browser reuses its connection. The slow segment is an origin database query. Adding more DNS servers will not help. Instrument edge time, upstream time, application time, and database time separately. Compare p50 and p99; an acceptable average can hide a poor experience for a meaningful minority of requests.

Failure walkthrough

Suppose POST /orders reaches the origin, commits an order, and loses the response on the return path. The client sees a timeout, but the system has an order. A network timeout means the caller lacks a result, not that the operation failed. A retry with the same idempotency identity or a status lookup resolves this uncertainty without blindly creating another order.

Figure — Client sends order → Origin commits order → Response is lost → Client sees timeout → Same-key retry finds order

Decisions and trade-offs

Check your understanding

Trace the first request and a later request to the same HTTPS API. Which setup steps might be reused?

Transfer to a new scenario

Trace a browser opening a dashboard and then calling its API; identify the separate DNS and application exchanges.

Does every request travel through the authoritative DNS server?

Continue the connection

Study API Design and explain which guarantee from this lesson carries into that topic.

Follow one browser request

Typing a URL starts several distinct operations. DNS resolves the hostname to a destination; it is not normally a proxy that forwards the HTTP request. Cached DNS answers may avoid a resolver round trip. The browser then establishes or reuses a transport connection, negotiates security as needed, and sends an HTTP request. A CDN edge may answer from cache or forward to an origin. Each of these boundaries can fail independently.

For an API hostname, DNS may direct traffic to a gateway or load balancer. For a website hostname, it may direct traffic to a CDN. The hostname alone does not determine the architecture; the DNS records and serving configuration do. WAF rules inspect supported application traffic at the configured boundary, while network DDoS protection addresses a different layer of attack.

Choose protocols by the contract

Do not describe WebSocket as durable delivery. A connection can disappear after the server sends bytes and before the client records them. Message IDs, acknowledgements, retained history and resume cursors address that uncertainty. Polling can be the right choice when updates are infrequent and operational simplicity matters.

Latency budgets and deadlines

Suppose a fictional request has a 300 ms deadline. Spend 30 ms on edge and routing, 40 ms on application work, 150 ms on dependencies, and reserve 80 ms for network variation and response work. These are a budget, not measured universal timings. If the first dependency consumes 140 ms, the second must not start with a fresh 300 ms timeout.

Propagate an absolute deadline or remaining budget. Bound connection acquisition as well as socket reads. A request can wait in a pool without ever reaching the remote service. Cancel work when the caller no longer needs it, while recognizing that cancellation does not undo an already committed side effect.

Retry without creating a storm

Retry transient failures only within an overall deadline and attempt budget. Add jitter so many clients do not retry at the same instant. If three layers each retry three times, one original request can produce 27 downstream attempts. Assign retry ownership deliberately and expose attempt counts in tracing.

A timeout does not tell you whether the remote operation committed. Reads are usually easier to retry; mutating requests need a stable operation key or a way to query the outcome. A circuit breaker can stop repeated calls to an unhealthy dependency, but it needs a recovery probe and should not become a permanent failure state.

Load balancers and connection state

A layer-4 balancer routes transport connections; a layer-7 proxy can route using HTTP properties after the appropriate termination point. Long-lived connections can distribute unevenly because one connection may carry much more work than another. Monitor active work and bytes, not only connection counts.

Connection draining lets existing work finish while a node leaves service. Idle timeouts must align across browser, proxy and application or apparently healthy streams will disconnect repeatedly. Keep application state recoverable outside the connection-owning process so a gateway replacement does not lose durable messages.

A concrete failure exercise

A client times out after submitting an order through a gateway. The database shows the order, but the client received no response. Should the client create a new order?

Protocol references

HTTP semantics, RFC 9110 and QUIC transport, RFC 9000 define the underlying protocol behavior. The latency budgets above are teaching assumptions.