The Client-Server Model: The Backbone of the Web

Every time you open a website, two computers strike up a quiet conversation. One asks for something, the other hands it over. This simple back-and-forth, repeated billions of times a day, is what keeps the entire World Wide Web running. The arrangement behind it is called the client-server model, and it is the communication architecture that decides how information travels from a distant machine to the screen in front of you. Once you understand this model, the web stops feeling like magic and starts looking like a well-organised system of requests and replies.

What is the client-server model? 🔗

The client-server model is a network architecture in which clients send requests for resources or services, and servers process those requests and return the required responses. Two roles sit at the heart of it. The client is the program that asks for something, usually a web browser on your phone or laptop. The server is a powerful, always-on computer that stores resources and answers those requests.

The division of work is the whole point. The model is a distributed structure that splits tasks between the providers of a service, called servers, and the requesters of that service, called clients. Clients handle what you see and interact with. Servers handle storage, processing, and the heavy lifting. Clients do not share their own resources with each other; they simply make requests and wait for answers.

This is why the web feels reliable. A single server can answer many clients at the same time, and because data and services are controlled centrally from servers, security and consistency improve. Email, online banking, and the World Wide Web all run on this same foundation.

How web services actually function 🔗

Picture what happens when you check train timings on a website. Your browser, the client, sends a request to the railway’s server. The server looks up the data, packages it, and sends a response back. Your browser then displays it. The server never came to you, and you never went to the server. Everything happened through messages passed over the network.

This request-response mechanism is the engine of every web service. The client initiates a request, the server processes it and returns results, and the client displays the response on screen. What you see in your browser is always the end product of this exchange. The same logic powers a search engine, a shopping site, and a video platform; only the type of resource being requested changes.

Standardising web information 🔗

For a client and server to communicate, they need a shared language for the content itself. This is where markup languages come in. A server may store information in many ways, but before that information reaches a browser, it needs a standard format the browser can read and display. Two markup languages dominate this task: HTML and XML.

The role of HTML 🔗

HyperText Markup Language (HTML) is the standard language used to structure content on the web. It uses a fixed set of tags to define headings, paragraphs, links, images, and lists. When a browser receives an HTML document, it knows exactly how to arrange these elements on the page because HTML tags are predefined and come from a set list defined by the HTML standard, the current version being HTML5.

HTML focuses on presentation and structure. It determines how information is delivered to the user and how the page is laid out. It is also an open standard maintained through ongoing collaborative work rather than being owned by any single company, which is exactly why a page written once can be read by any browser anywhere. The “hypertext” part refers to the links between documents, which is what makes the web a connected web rather than a pile of separate pages.

The role of XML 🔗

Extensible Markup Language (XML) takes a different approach. While HTML decides how data looks, XML’s primary function is to label and structure information, allowing for clear data organisation rather than presentation. It was developed by the World Wide Web Consortium (W3C) in the late 1990s and has its roots in SGML, an older documentation standard.

The key difference is flexibility. In HTML the tags are fixed, but XML tags are extendable, meaning the document creator defines their own tags and attributes to describe the data. A library catalogue, for instance, could use tags like <author> and <title> that carry meaning a machine can process. Because XML is platform independent, it lets data move between different programs and devices regardless of their underlying software or hardware. This makes XML the preferred choice for transporting structured data between systems, while HTML remains the choice for displaying pages to people.

HTTP: the core protocol of the web 🔗

Knowing the roles of client and server, and having a standard format for content, still leaves one question: how do the messages travel? The answer is the HyperText Transfer Protocol (HTTP). HTTP is the set of rules that governs how web browsers and web servers talk to each other.

It is an application-layer protocol for transmitting hypermedia documents such as HTML, designed for communication between browsers and servers. When you type a web address and press Enter, your browser sends an HTTP request to the server, and the server replies with an HTTP response. That response usually contains the HTML of the page you asked for, which your browser then renders.

The structure of an HTTP message 🔗

Every HTTP message follows a clear structure, which is what allows any browser to talk to any server. HTTP messages are made up of a start-line describing the request method or response status, optional header fields carrying extra information, and an optional body containing the actual data. A request also names a method such as GET, used to fetch a resource, or POST, used to send data to the server.

HTTP is also media independent. It can carry any type of content, from text and images to audio and video, as long as both the client and server agree on the format. This is why the same protocol can deliver a news article, a song, and a video clip without needing a separate system for each.

Stateless protocols and addressing 🔗

One feature of HTTP surprises many students at first. The protocol has no memory. HTTP is a stateless protocol, meaning the server does not keep any session data between two requests. Each request is treated as a brand-new, independent transaction.

Why statelessness matters 🔗

Being stateless means each data exchange is independent of previous exchanges, so the server does not store a history of a client’s earlier requests. This sounds like a limitation, but it is a deliberate design choice. It keeps servers simple and lets them handle huge numbers of requests, because they do not have to remember every visitor.

The obvious question follows: if the server forgets you after every request, how does a shopping cart stay full, or how do you stay logged in? The answer is that statelessness does not mean memoryless at the application level; the protocol simply does not require stored conversation history to process the next request. Tools like cookies and sessions were added on top of HTTP to carry identifying information with each request, restoring a sense of memory without changing the protocol’s stateless nature.

Addressing: finding the right server 🔗

Before any request can be sent, the client needs to know where to send it. This is the job of addressing. You type a human-friendly web address, but computers communicate using numerical IP addresses. The Domain Name System (DNS) bridges this gap. DNS resolution is the process of converting a hostname such as www.example.com into a computer-friendly IP address.

The full web address you type is called a Uniform Resource Locator (URL). While a domain identifies a website, a URL identifies a specific resource on that website, such as a particular page or file. So the URL tells the browser both which server to reach and exactly which resource to request once it gets there. Only after DNS returns the IP address can the browser make its HTTP request and the server return the web page.

Examples of web communication 🔗

Bringing all these pieces together explains what happens in the second between pressing Enter and seeing a page. The journey runs through a predictable sequence of steps.

How a browser fetches and renders a page 🔗

First, you enter a URL. The browser cannot use the domain name directly, so it asks a DNS resolver to translate it. The query travels through a recursive resolver, root name servers, TLD name servers, and finally an authoritative server that holds the exact IP address for the domain.

Once the browser has the IP address, the request-response cycle begins. A browser sends an HTTP request to the web server, the server receives and processes it, runs an application if needed, returns an HTTP response, and the browser receives that response. The connection in classic HTTP exists only for the duration of that exchange.

The response typically contains an HTML document. The browser parses this HTML, and whenever it finds references to other resources such as images, stylesheets, or scripts, it sends fresh requests for each of them. After receiving the root file, the browser makes further requests for external resources, parses the HTML, CSS, and JavaScript, and finally renders the website on screen. Each of those extra requests is its own independent, stateless transaction, which is the stateless model in action.

Consider opening Gmail. Your browser resolves the address through DNS, sends an HTTP request, and receives HTML in return. A cookie attached to that request tells the server who you are, so the page loads with your name and inbox even though HTTP itself remembers nothing. Every refresh repeats the cycle from scratch. This same pattern, multiplied across every site you visit, is the working reality of the client-server model.

Why this architecture endures 🔗

The client-server model has lasted because each part does one job well. Clients present and interact, servers store and process, markup languages standardise the content, HTTP moves it, and DNS finds the right destination. The statelessness of HTTP keeps the system scalable, while cookies and sessions layered on top supply the personalisation users expect. It is a clean separation of responsibilities, and it scales from a single small website to services used by billions.

What do you think? If HTTP is stateless and servers forget you after every request, what trade-offs do you see between this simplicity and the convenience of staying logged in across a session? And as more of our daily services move online, how important is it for students of information science to understand the communication architecture working quietly beneath every click?

References

1. https://www.geeksforgeeks.org/system-design/client-server-model/
2. https://jumpcloud.com/it-index/what-is-the-client-server-model
3. https://blog.algomaster.io/p/client-server-architecture-explained
4. https://aws.amazon.com/compare/the-difference-between-html-and-xml/
5. https://html.spec.whatwg.org/
6. https://www.ebsco.com/research-starters/computer-science/xml-extensible-markup-language
7. https://developer.mozilla.org/en-US/docs/Web/HTTP
8. https://academy.nordicsemi.com/courses/wi-fi-fundamentals/lessons/lesson-5-wifi-fundamentals/topic/http-protocol/
9. https://www.ituonline.com/tech-definitions/what-is-a-stateless-protocol/
10. https://www.cloudflare.com/learning/dns/what-is-dns/
11. https://cleanbrowsing.org/learn/domain-vs-url-vs-ip
12. https://www.fortinet.com/resources/cyberglossary/what-is-dns
13. https://www.slideshare.net/slideshow/lecture-6-http/240329460
14. https://educative.io/courses/web-development-interview-handbook/from-entering-a-url-to-receiving-root-file