FoundationalNetworkingFree Preview

Client-Server Architecture Explained — How Web Requests Work

A request moves from browser to DNS, TCP, TLS, HTTP, load balancer, app, storage, and back.

Every time you type a web address and press Enter, a journey begins that involves at least 6 distinct layers of technology, each with its own latency contribution, failure mode, and optimization opportunity. Understanding this journey is the foundation of all system design work.

The sequence: (1) Browser checks its DNS cache. On miss, it queries a recursive resolver to convert the domain name to an IP address. (2) The browser opens a TCP connection to that IP — a three-way handshake (SYN, SYN-ACK, ACK) that costs 1 round-trip time. (3) TLS negotiation adds another 1-2 RTTs to establish an encrypted channel. (4) The HTTP request travels through a load balancer to an application server. (5) The app queries a database or cache and builds the response. (6) The response travels back the same path.

The total latency budget is roughly: DNS (20-100ms) + TCP (10-60ms) + TLS (10-60ms) + server processing (10-200ms) + response transfer (10-100ms). Every millisecond over the user's threshold (typically 200ms for page loads, 100ms for API calls) affects conversion and retention.

Key concepts

browserTCPTLSHTTP/1.1HTTP/2HTTP/3keep-alive

Step-by-step approach

1
Browser checks its local DNS cache; on miss, queries the recursive resolver to get the server's IP address.
2
Browser opens a TCP connection to the resolved IP: three-way handshake (SYN, SYN-ACK, ACK) costs 1 RTT.
3
TLS handshake establishes an encrypted channel — TLS 1.3 costs 1 additional RTT; older TLS 1.2 costs 2.
4
HTTP request is sent. HTTP/2 multiplexes multiple requests over one TCP connection; HTTP/3 uses QUIC (UDP) to eliminate head-of-line blocking.
5
Application server processes the request, queries the database or cache, and sends the HTTP response back through the same path.

Key trade-offs

HTTP/1.1 vs HTTP/2

HTTP/1.1 requires multiple TCP connections for parallelism (6 per browser); HTTP/2 multiplexes on one connection, reducing connection overhead and improving throughput.

Short-lived vs keep-alive connections

Closing connections after each request wastes the TCP and TLS setup cost. Keep-alive reuses connections but holds server resources open.

TCP vs UDP (HTTP/3)

TCP guarantees ordering and delivery but suffers from head-of-line blocking. QUIC/HTTP3 uses UDP with per-stream ordering to eliminate this at the cost of implementation complexity.

Common pitfalls

⚠

Ignoring TLS termination placement: terminating TLS at the load balancer vs. at the application server changes your security boundary and affects certificate management.

⚠

Not accounting for RTT in latency budgets: a geographically distant server adds 100-300ms of round-trip time regardless of how fast your application code runs.

⚠

Forgetting DNS TTL in failover planning: if your DNS TTL is 5 minutes and a server goes down, clients will keep hitting the failed IP for up to 5 minutes.

Interview questions on this topic

Walk me through everything that happens when a user types 'twitter.com' into their browser and presses Enter.

Where would you place TLS termination in a multi-tier web architecture, and why?

Practice answering these with AI feedback → Start on CrackLab

Continue learning — explore 207 more topics on CrackLab DesignHub

From Classic HLD designs (Twitter, YouTube, Uber) to LLD patterns, distributed systems, databases, and company case studies.

Start Learning Free →See all 208 topics