Application Layer·Lesson 2 of 12
Client-Server Communication
Who Asks and Who Answers
Most of the things you do online follow one simple pattern: one side asks, the other side answers. The side that asks is the — for example, your web browser or email app. The side that waits for requests and responds to them is the — the machine hosting the website or storing your mail. Nearly every application-layer protocol you'll meet (HTTP, FTP, SMTP, and the rest) is built on this back-and-forth between a client and a server.
The core rule
The client always starts the conversation. The server never reaches out first — it sits and listens, then replies to whoever asks. This is called the request-response model.
A customer and a kitchen
You (the client) look at the menu and place an order. The kitchen (the server) is always open during business hours, waiting for orders. It prepares your dish and sends it out. The kitchen never cooks for you until you ask, and it can take orders from many tables at once — exactly how a server behaves.
The Request-Response Cycle
Every client-server exchange follows the same handful of steps. The server has to be up and listening first; then the client reaches out, asks, and waits for the reply. Here is the full cycle from start to finish:
How one exchange plays out
- The server starts up and listens for requests on a known port number
- The client figures out the server's address — often by looking up its name through DNS
- The client opens a connection to that address and port
- The client sends a request message describing what it wants
- The server processes the request and sends back a response
- The connection is closed, or kept open and reused for more requests
How a Client Finds the Right Server
To reach a server, a client needs two pieces of information: which machine to talk to, and which program on that machine. The machine is identified by an — a numeric address like 142.250.4.100. The program is identified by a number — a small number that says "deliver this to the web server" versus "deliver this to the mail server." Since IP addresses are hard to remember, clients usually start with a name like example.com and use to look up the matching IP address first.
IP + port = socket
An IP address and a port together form a socket — the exact endpoint of a connection. "142.250.4.100:443" means "the HTTPS server on that machine." A connection is really just a link between two sockets.
Client vs Server at a Glance
The two roles are opposites in almost every way. The client is temporary and active; the server is long-running and reactive. This table lines them up side by side:
| Client | Server | |
|---|---|---|
| Role | Asks for a service | Provides a service |
| Who starts | Initiates the connection | Waits and listens |
| Runs when | Only while you use it | Continuously, always on |
| Knows about | One server at a time | Many clients at once |
| Example | Browser, email app | Web server, mail server |
One Server, Many Clients
A single server usually talks to thousands of clients at the same time. It keeps listening on its port, and each time a new client connects, it handles that request alongside all the others. This is why the client-server model scales so well for services like websites: you add capacity in one place — the server — and every client benefits. The trade-off is that if the server goes down, every client loses access at once, so real systems add backups and spread the load across several servers.
Not every application uses this model. In a setup, there's no dedicated server at all — every device acts as both a client and a server, asking for and providing data to its equals. File-sharing networks work this way. But for the application-layer protocols in this topic, the client-server pattern is the norm.
“"A server has to be a big, powerful machine in a data center."”
Q:Why does the client always initiate the connection, not the server?
A: Because the server doesn't know in advance who will want its service or when. It can't reach out to millions of unknown clients, so it does the opposite: it stays at a fixed, well-known address and port and waits. Any client that knows that address can connect whenever it needs to. This keeps servers simple and lets any number of clients find them the same way.
Quick Revision Cheat Sheet
Client: Asks for a service and starts the connection
Server: Waits, listens, and answers requests
Request-response: Client asks, server replies — the core pattern
To reach a server: Need its IP address (which machine) + port (which program)
Socket: IP address + port — the endpoint of a connection
Alternative: Peer-to-peer, where every device is both client and server