How the Web Works: Clients, Servers, and Browsers

How the Web Works: Clients, Servers, and Browsers

The Client-Server Model

Every time you load a web page, two kinds of computers are involved: a client and a server. The client is the device you are using — your laptop, phone, or desktop — along with the software running on it, typically a web browser. The server is a computer (or cluster of computers) located somewhere on the internet that stores the files and data making up the website.

The relationship is straightforward: the client asks for something, and the server responds. This is called the client-server model. Neither side can do the other's job. The browser does not store the website permanently; the server does not display anything to a user. Each plays a distinct role.

Domain Names and DNS

Before a browser can contact a server, it needs to know the server's numerical address, called an IP address (for example, 93.184.216.34). People, however, use human-readable names such as `example.com`. The Domain Name System (DNS) acts as the internet's phone book: it translates a domain name into the corresponding IP address.

When you type a URL into the browser's address bar, the browser first checks its own cache. If the address is not there, it contacts a DNS resolver — usually provided by your internet service provider or a public DNS service — which looks up and returns the correct IP address. Only after this lookup can the browser open a connection to the server.

HTTP and the Request-Response Cycle

HTTP (HyperText Transfer Protocol) is the agreed set of rules that clients and servers use to communicate. Most sites today use HTTPS, the secure version, which encrypts the data in transit using TLS (Transport Layer Security). This encryption protects users from having their data intercepted — a real-world safety concern whenever sensitive information such as passwords or payment details is involved.

The browser sends an HTTP request to the server. Every request includes:

• An HTTP method that describes the intended action. The most common are GET (retrieve a resource) and POST (send data to the server). Others include PUT, PATCH, and DELETE.
• A URL identifying the specific resource.
• Headers carrying extra information such as the browser type and accepted content formats.
• Optionally, a body containing data (common with POST).

The server processes the request and sends back an HTTP response. Every response includes:

• A status code indicating the outcome. Common codes include 200 OK (success), 301 Moved Permanently (redirect), 404 Not Found (resource missing), and 500 Internal Server Error (server-side problem).
• Headers describing the response content.
• A body containing the actual resource — often an HTML document.

How the Browser Renders a Page

Receiving the HTML file is only the beginning. The browser must parse and render that file before the user sees anything. This process follows a defined order:

1. HTML parsing — The browser reads the HTML and builds the DOM (Document Object Model), a tree structure representing every element on the page.

2. CSS parsing — As the browser encounters `<link>` tags or `<style>` blocks, it fetches and parses CSS, building the CSSOM (CSS Object Model).

3. Render tree construction — The DOM and CSSOM are combined into a render tree that includes only the elements that will actually be displayed.

4. Layout — The browser calculates the size and position of every element.

5. Paint — Pixels are drawn to the screen.

6. JavaScript execution — When the browser meets a `<script>` tag, it pauses HTML parsing by default, fetches and executes the script, then continues. This is why placing scripts at the bottom of the `<body>` or using the `defer` attribute is a common best practice — it prevents JavaScript from blocking the initial render.

Static vs. Dynamic Websites

A static website serves the same pre-built HTML, CSS, and JavaScript files to every visitor. The content does not change unless a developer manually updates the files. Personal portfolios and simple informational sites are often static.

A dynamic website generates content on the server (or in the browser) in response to each request. A news site that shows different articles to different users, or an e-commerce site that displays your shopping cart, is dynamic. Dynamic sites typically involve server-side languages (such as Python or Node.js), databases, and APIs.

Professional and Safety Considerations

Understanding HTTPS is not just academic. As a developer, you are responsible for ensuring that any site handling user data uses HTTPS. Serving sensitive content over plain HTTP exposes users to man-in-the-middle attacks, where an attacker intercepts and reads or modifies traffic. Most browsers now warn users when a site lacks a valid TLS certificate, and search engines may rank unencrypted sites lower. Always obtain and configure a valid certificate for production sites.

Additionally, be careful with status code handling: a server that reveals detailed error messages (such as stack traces) on a 500 response can expose internal details to attackers. In production, log errors server-side and return generic messages to the client.