Every field has its own vocabulary, and the web is no exception. When you start learning how websites work, you bump into the same handful of words again and again: client, server, request, HTTP, DNS, hosting. If nobody has ever stopped to explain them plainly, they can feel like a wall between you and the topic you actually want to understand.
This article is that explanation. Think of it as a small dictionary you can keep open in another tab. Each term gets one clear definition, a simple analogy where it helps, and just enough context to see how it connects to the others. You do not need to read it top to bottom in one sitting. Skim for the word you got stuck on, get the idea, and move on. Over time these words stop being jargon and start being tools you think with.
To make everything click, we will group the terms by the role they play rather than listing them alphabetically. By the end you will be able to read a sentence like “the browser sends an HTTP request to the server” and picture exactly what is happening.
The two sides: client and server
Almost everything on the web is a conversation between two parties. Naming them is the first step.
A client is the program that asks for something. Most of the time the client is your web browser, but it can also be a mobile app or another piece of software. The client starts the conversation: it wants a page, an image, or some data.
A server is the computer (and the software running on it) that listens for those requests and answers them. It sits somewhere in a data center, waiting. When a request arrives, the server figures out what was asked for and sends back a reply. The name is literal: it serves things.
A helpful way to picture it is a restaurant. You, the customer, are the client. You place an order. The kitchen is the server: it receives your order, prepares the dish, and sends it out. You do not see the kitchen work, you just get your plate.
CLIENT SERVER
┌────────┐ request ───▶ ┌────────┐
│ browser│ │ kitchen│
│ (you) │ ◀─── response │ (data) │
└────────┘ └────────┘Client and server are roles, not machines
The same computer can be a client in one moment and a server in another. “Client” and “server” describe what a program is doing in a given exchange, not a fixed type of hardware.
The conversation: request and response
The two messages that travel between client and server have names too.
A request is the message the client sends to ask for something. It says, in effect, “please give me this page” or “here is some data to save.” A request carries details: what is wanted, who is asking, and sometimes extra information attached to it.
A response is the reply the server sends back. It might contain the web page you asked for, an image, some data, or simply a status that says “done” or “not found.” Every request the client makes gets exactly one response in return.
Put together, the rhythm of the web is just request, response, request, response, repeated thousands of times as you browse. Click a link, and your browser sends a request; the page that appears is the response.
The rules of the conversation: protocol and HTTP
For two computers to understand each other, they have to agree on how to talk. That agreement is called a protocol — a set of rules for the format of messages and the order they come in. A protocol is like the etiquette of a phone call: you say hello, the other person responds, you take turns, you say goodbye. Without shared etiquette, it is just noise.
HTTP stands for HyperText Transfer Protocol, and it is the specific protocol the web uses to move pages and data between clients and servers. When your browser asks for a page, it phrases the request in HTTP, and the server answers in HTTP. You have probably seen it at the start of web addresses.
HTTPS is the same protocol with a layer of encryption added (the “S” stands for Secure). It scrambles the messages so that anyone snooping on the connection cannot read them. Today the vast majority of websites use HTTPS, which is why your browser shows a padlock.
GET /about HTTP/1.1
Host: acy-partner.comThat tiny example is a request written in HTTP: the client is asking to GET the page at /about from the host acy-partner.com. The server would respond with the page and a status code telling the browser how things went.
| Term | One-line meaning |
|---|---|
| Protocol | An agreed set of rules for how two computers exchange messages |
| HTTP | The protocol the web uses to transfer pages and data |
| HTTPS | HTTP with encryption added, so the messages stay private |
Naming and finding things: URL, domain, DNS, and IP
Once you know how the conversation works, the next question is: how does the client know where to send the request? A few terms handle the addressing.
A URL (Uniform Resource Locator) is the full address of something on the web — what you type into the address bar. A URL has parts: the protocol (https://), the domain (acy-partner.com), and often a path to a specific page (/blog/glossary). It points to one exact resource.
A domain (or domain name) is the human-friendly name of a website, like acy-partner.com or blog.acy-partner.com. It is the part people actually remember and type. Domains exist because the real addresses computers use are far harder to memorize.
An IP address is that real address: a string of numbers (for example 93.184.216.34) that uniquely identifies a computer on the internet. Every server has one. Computers route messages using IP addresses, not friendly names.
So if people use domains but computers use IP addresses, something has to translate between them. That something is DNS (the Domain Name System). DNS is the phone book of the internet: you give it a domain name, and it hands back the matching IP address so your request can find the right server.
You type: blog.acy-partner.com
│
▼ (DNS lookup)
DNS answers: 93.184.216.34 ← the IP address
│
▼
Browser sends the request to that IPA simple way to remember the chain
You type a domain, which is part of a URL. DNS turns that domain into an IP address, and your request travels to the server at that IP. Domain for humans, IP for machines, DNS as the translator.
The thing you look at: browser
A browser is the program you use to visit websites — Chrome, Firefox, Safari, Edge, and others. It is the most common kind of client. Its job is bigger than it looks: the browser sends requests, receives the responses, and then turns the raw code in those responses into the page you see, complete with text, images, colors, and buttons. It also runs the small programs that make pages interactive.
In short, the browser is your window onto the web. Everything else in this glossary is mostly invisible; the browser is the part you touch directly.
Building the website: frontend and backend
When people talk about making websites, two words split the work in half.
The frontend is everything that happens in the browser — the part the user sees and interacts with. Layout, colors, text, buttons, animations: that is the frontend. It runs on the client side, on your device.
The backend is everything that happens on the server, out of sight. It handles the logic, stores and retrieves data, checks who is logged in, and decides what to send back. When you submit a form and your information gets saved, that work is the backend doing its job.
A useful image is a building. The frontend is the lobby and the rooms you walk through — the part designed for people. The backend is the plumbing, wiring, and foundation behind the walls: essential, but not something visitors are meant to see.
| Term | Runs where | Roughly responsible for |
|---|---|---|
| Frontend | In the browser (client) | What you see and interact with |
| Backend | On the server | Logic, data, and decisions behind the scenes |
Putting it online: hosting and CDN
A website built on someone’s laptop is not yet on the web. Two more terms cover getting it out to the world and keeping it fast.
Hosting means renting space on a server that is always on and connected to the internet, so your website’s files live somewhere the public can reach at any hour. A hosting provider is a company that owns those servers and rents them out. Without hosting, there is no public address for people to visit.
A CDN (Content Delivery Network) is a network of servers spread across many locations around the world, each keeping a copy of your site’s files. When someone visits, they are served from the location nearest to them. The result is a faster load, because the data travels a shorter distance. A visitor in Jakarta gets files from a nearby server instead of one on the other side of the planet.
Hosting and CDN work together
Hosting is the home where your site lives. A CDN is a set of fast delivery points that copy parts of your site closer to your visitors. You can have hosting without a CDN, but a CDN almost always sits in front of hosting, not instead of it.
A quick reference table
Here is the whole glossary in one place, so you can scan it later without rereading the sections.
| Term | Short definition |
|---|---|
| Client | The program that asks for something (usually your browser) |
| Server | The computer that listens for requests and sends back answers |
| Request | The message a client sends to ask for a page or data |
| Response | The reply the server sends back |
| Protocol | An agreed set of rules for how computers exchange messages |
| HTTP | The protocol the web uses to transfer pages and data |
| HTTPS | HTTP with encryption, so messages stay private |
| URL | The full web address of a specific resource |
| Domain | The human-friendly name of a website |
| IP address | The numeric address that identifies a computer online |
| DNS | The system that turns a domain into an IP address |
| Browser | The program you use to visit and view websites |
| Frontend | The part of a site that runs in the browser and you interact with |
| Backend | The part that runs on the server and handles logic and data |
| Hosting | Rented space on an always-on server where your site’s files live |
| CDN | A network of servers that delivers your files from a location near each visitor |
Recap
The web runs on a simple loop: a client sends a request to a server, and the server sends back a response. They understand each other because they share a protocol — on the web, that is HTTP (or its encrypted form, HTTPS). To find the right server, your browser starts from a URL, reads the domain inside it, and uses DNS to look up the matching IP address.
The program doing all this on your side is the browser. The site itself is split into a frontend (what you see) and a backend (what runs on the server). And to be reachable at all, the site needs hosting, often with a CDN in front to keep it fast for visitors everywhere.
Keep this page bookmarked. As you read more about how the web works, you will meet these words constantly, and each time you do, you will recognize an old friend rather than a new obstacle. From here, a natural next step is to follow any single term down to its own deeper explanation — how an HTTP request is structured, or what really happens during a DNS lookup — now that you know where each piece fits in the bigger picture.
