The Basic Model
In the client-server model, two roles exist:
- Client: The entity that initiates requests. Browsers, mobile apps, CLI tools, and other services can all act as clients.
- Server: The entity that listens for requests, processes them, and returns responses. Servers typically run continuously, waiting for incoming connections.
The interaction follows a simple pattern: the client sends a request, the server processes it and returns a response. This is called the request-response cycle.
How a Web Request Works (Step by Step)
When you type a URL in your browser and press Enter, a long sequence of events unfolds. Understanding this sequence is essential:
DNS Lookup
The browser asks a DNS server to resolve the domain name (e.g., example.com) into an IP address (e.g., 93.184.216.34). This may involve multiple DNS servers: recursive resolvers, root servers, TLD servers, and authoritative servers.
TCP Connection
The browser opens a TCP connection to the server's IP address on port 80 (HTTP) or 443 (HTTPS). This involves a three-way handshake: SYN, SYN-ACK, ACK.
TLS Handshake (HTTPS only)
If using HTTPS, the client and server perform a TLS handshake to establish an encrypted channel. They agree on a cipher suite, exchange certificates, and derive session keys.
HTTP Request
The browser sends an HTTP request containing the method (GET, POST, etc.), path, headers (cookies, content-type, auth tokens), and optionally a body.
Server Processing
The server receives the request, routes it to the appropriate handler, executes business logic (potentially querying a database or cache), and constructs a response.
HTTP Response
The server sends back a response with a status code (200, 404, 500, etc.), headers, and a body (HTML, JSON, binary data, etc.).
Rendering / Processing
The client processes the response. A browser parses HTML and renders the page. An API client deserializes JSON and acts on the data.
Stateless vs. Stateful Servers
A critical architectural decision is whether the server maintains state between requests.
Stateless Servers
- Each request is independent. The server does not remember previous requests.
- State (user sessions, auth) is stored externally: in a database, cache, or JWT token.
- Easy to scale horizontally: any server can handle any request.
- Used by most modern web applications.
Stateful Servers
- The server remembers previous interactions with a client.
- Requires "sticky sessions": routing the same client to the same server.
- Harder to scale: losing a server loses the sessions.
- Used when persistent connections are needed (e.g., WebSocket-based chat).
Architectural Variants
Single Server
The simplest deployment: one machine runs the web server, application logic, and database. Suitable for prototypes and small projects with minimal traffic. The entire system is a single point of failure.
Separated Database
The application server and database run on separate machines. This allows you to scale them independently and choose hardware optimized for each workload (CPU for the app, disk/memory for the database).
Multi-Server with Load Balancer
Multiple application servers sit behind a load balancer. The load balancer distributes incoming requests across the servers. This provides redundancy (if one server dies, others continue) and higher throughput. Covered in depth in Chapter 6.
Peer-to-Peer (P2P)
In P2P architecture, every node acts as both client and server. There is no central authority. BitTorrent and blockchain networks use this model. P2P is excellent for distributing large files but introduces complexity in coordination, discovery, and consistency.
HTTP Methods
HTTP defines methods that indicate the desired action on a resource:
| Method | Purpose | Idempotent | Body |
|---|---|---|---|
| GET | Retrieve a resource | Yes | No |
| POST | Create a new resource | No | Yes |
| PUT | Replace a resource entirely | Yes | Yes |
| PATCH | Partially update a resource | No* | Yes |
| DELETE | Remove a resource | Yes | No |
| HEAD | Same as GET but no body in response | Yes | No |
| OPTIONS | Describe communication options | Yes | No |
HTTP Status Codes
Status codes tell the client what happened with their request:
- 2xx (Success): 200 OK, 201 Created, 204 No Content
- 3xx (Redirection): 301 Moved Permanently, 302 Found, 304 Not Modified
- 4xx (Client Error): 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests
- 5xx (Server Error): 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout
Connection Types
Short-Lived Connections (HTTP/1.0)
Each request opens a new TCP connection, sends the request, receives the response, and closes the connection. Inefficient because TCP and TLS handshakes are expensive.
Persistent Connections (HTTP/1.1 Keep-Alive)
The TCP connection is reused for multiple requests. This eliminates repeated handshake overhead. HTTP/1.1 enables this by default.
Multiplexed Connections (HTTP/2)
Multiple requests and responses can be in-flight simultaneously over a single TCP connection while avoiding head-of-line blocking at the HTTP layer. Server push allows anticipatory sending of resources.
WebSockets
A full-duplex communication channel over a single long-lived TCP connection. After an initial HTTP handshake, both client and server can send messages independently at any time. Used for real-time applications: chat, live feeds, gaming, collaborative editing.
Server-Sent Events (SSE)
A one-way channel where the server pushes updates to the client over a long-lived HTTP connection. Simpler than WebSockets when you only need server-to-client updates. Used for live dashboards, notifications, and activity streams.
Key Takeaways
- The client-server model is the backbone of web architecture. Understand the request-response cycle deeply.
- Prefer stateless servers and externalize state to dedicated stores.
- Separate application servers from databases early: it is a prerequisite for scaling.
- Choose the right connection type based on your communication pattern: request-response (HTTP), real-time bidirectional (WebSocket), or server push (SSE).
- Know your HTTP methods and status codes: they are the vocabulary of API communication.
Chapter Check-Up
Quick quiz to reinforce what you just learned.