the client-server model

Think of a restaurant. The kitchen is always there, always ready, waiting for orders. Customers come and go; they ask, the kitchen answers. Nobody walks into a restaurant expecting to cook for the kitchen. The client-server model is exactly this asymmetry on the Internet: one side (the server) is an always-on program with a known, fixed address that waits for requests; the other side (the client) is the program that initiates the conversation and asks for something.

Concretely, a server process starts up, opens a socket on a well-known port (a web server on TCP port 80 or 443), and then blocks, waiting. A client — your browser — knows the server's address and port, connects to it, sends a request, and reads back a response. The client always speaks first; the server only ever answers. The server typically handles many clients at once, each through its own connection, while no client ever talks to another client directly — all communication flows through the server in the middle.

This model dominates the web, email, and most online services because it is simple to build and easy to control: the data and the logic live in one trusted place that the operator runs and secures. Its weaknesses are the flip side of its strength — the server is a single point of failure and a bottleneck. If a million clients want the same file at once, that one server (or its data centre) must serve them all, which is exactly the scaling problem that peer-to-peer designs and content delivery networks try to dodge.