Client, server, and the request–response idea

You type college.edu/results and hit Enter. For half a second nothing happens — then the whole page appears. Something out there heard you.

Why & what

Why this exists. Data has to live somewhere. Your results are not on your laptop — if they were, you could edit them. They sit on one machine the college controls, and thousands of students read from it.

So we need a clear split: one side that asks, and one side that keeps the data and answers.

What it is.

• A client is the side that starts the conversation and asks for something. Your browser is a client.
• A server is the side that sits waiting and answers when asked. The machine holding the results page is the server.
• A request is the message that goes out. A response is what comes back.

This whole arrangement is called the client–server model.

The key rule: the server never speaks first. It waits. Always.

How it works

1. Aisha types the address. Her browser becomes the client.
2. Her laptop opens a connection to the server at 203.0.113.10.
3. It sends a request: what it wants (/results) and where to send the reply (192.168.1.42).
4. The server reads the request, fetches the page, and builds a response.
5. The response travels back to 192.168.1.42, and the browser draws it on screen.

Common confusion

Students think a server is a special, expensive, giant machine. Actually, "server" is a role, not a type of machine.

Any computer running software that waits and answers is a server. Your own laptop becomes a server the moment you start a local project on port 3000. The same laptop is a client in the browser tab next to it.

One more arrangement is worth naming: peer-to-peer (P2P), where every device is both client and server — torrents, or sharing files directly over Wi-Fi. No fixed middle machine.

Interview angle

Asked as: "Explain the client–server model" or "Difference between client–server and peer-to-peer."

Answer:

In the client–server model one side requests and the other responds. The client starts every conversation; the server waits and answers. The server holds the data, so it stays consistent for everyone. Server is a role, not hardware — one machine can be a client for one task and a server for another. In peer-to-peer there is no fixed server; every node is both. Client–server is easier to secure and control, peer-to-peer has no single point of failure.