How the Web Works: What is a web server?
Tags: webdev, programming, beginners, backend
Published: 2024-05-16 14:29:30

---
title: How the Web Works: What is a web server?
published: true
description: The other half of our client-server relationship
tags: webdev, programming, beginner, backend
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hcyiq1ml4qjen9qlq17v.png
# Use a ratio of 100:42 for best results.
# published_at: 2024-05-16 14:23 +0000
canonical_url: https://howthewebworks.substack.com/p/what-is-a-web-server
---

This article is part of the How the Web Works series I'm running over on Substack! If you're interested in following along, check it out here:

https://howthewebworks.substack.com

---

In the last edition of How the Web Works, we talked about the web client. We concisely defined web clients as fancy document viewers. This week, we’ll talking about the other half of the “client-server” relationship: web servers!

The web server is where our fancy document viewer, the web client, gets its documents (and other data). Web servers are just computers that are usually physically located in a different place than web clients. While a web client might be located on a user’s laptop or cell phone, web servers will be located in a facility somewhere. Technically, this could even be a computer in a company’s closet. More often, however, web servers are found in massive data centers maintained by big tech companies (e.g., Amazon, Microsoft, and Google).

## How clients and server work together

Let’s get a bit more specific about how web clients and web servers work together. One immediate question we need to answer:

>How do web clients even find web servers in the first place?

This is a great question and, like pretty much everything else in web technology, is complex enough that it will receive its own newsletter edition! In short: web clients locate web servers using the Domain Name System (DNS). For now, we can think of it like this:

- A user types www.example.com into their web browser’s URL bar and hits Enter
- The web browser asks a service called DNS the following question: “Where can I find the web server for www.example.com“
- DNS responds with the server’s IP address, which is used to route messages to the correct location.

Web clients and web servers communicate using Hypertext Transfer Protocol (HTTP), which again we’ll cover in much more detail in another edition! But in short, once a web client knows where a web server is, it can send a HTTP request. After the web server receives this request and decides what to do with it, it sends the client an HTTP response.

Putting this all together, we emerge with the following diagram:

![Simple client/server](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hcyiq1ml4qjen9qlq17v.png)

The web client uses DNS to find the web server’s location. Then, it sends an HTTP request to the web server asking for the page.html document. Finally, the web server sends an HTTP response back to the web client with the page.html document content.

## A more realistic picture

Realistically, web servers often connect to a bunch of different components like databases, file storage, and third-party services.

![Client/server with database, auth service, and file storage](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9dk197lnh0bjbj107vlu.png)

In this fictional scenario, the following happens:

- A user types www.example.com into their web browser’s URL bar and hits Enter
- The web browser asks a service called DNS the following question: “Where can I find the web server for www.example.com“
- DNS responds with the server’s IP address, which is used to route messages to the correct location.
- The web client sends an HTTP Request for page.html to the server
- The server uses a third-party authentication service to check if the user is allowed to access page.html. The authentication service says that the user is indeed allowed access.
- The server requests content from a database and a file storage service that is required to populate information in page.html.
- Once all that information is assembled, the web server sends an HTTP response with the page.html content.

Whew! Now we’re getting somewhere. A couple things to note about this flow: First, we haven’t covered a bunch of the concepts in this flow, so don’t worry if it feels a bit overwhelming. Second, this flow is still a lot simpler than a lot of real-life applications. But that’s okay—we’re just on the second newsletter in our How the Web Works series after all!

## Some important characteristics of web servers

While the web client is on the user’s device, you (or your company) has control over the web server. This has some really nice benefits!

### More predictable hardware and software

When writing code for web clients, we generally have to stick to the technology commonly supported by users’ browsers and devices. This means we’re mostly stuck with HTML, CSS, and JavaScript code. And even then, different clients have varying levels of support for features of these languages. Furthermore, if someone is using an old or low-powered client, they may have trouble even running web application code if that code is more demanding. In short: coding for clients can be pretty tricky due to all the variability!

Web servers, on the other hand, are much more predictable. You generally know the exact hardware and software specifications of your web server. You can install and run any languages you want. Some popular options include Java, Python, Ruby, and JavaScript, but really anything is fair game.

### A more secure environment

Web servers are more secure than web clients. While you should assume anyone can see information sent to their web client, it is reasonable to expect information you access on the web server will be private—unless you expose it. This means your web server can access a database that has information on all users in your system because your server code can pick which information to expose to web clients.

I should note here that securing your web servers is a big deal. The fact that web servers have access to protected information also makes them a target for bad actors. One large category of attacks is Remote Code Execution (RCE), where the attacker finds a way to run their code on your web server. If a bad actor does gain access to your web server, they could potentially gain access to user credentials, information about your users, trade secrets, etc.

Server security measures will mostly be outside the bounds of the How the Web Works material—security engineering is its own distinct profession and I wouldn’t do it justice.

### You have to figure out how to accommodate varying loads of web traffic

While each user has their own web client, we do not have that luxury with web servers. This means we can run into issues with overloading our servers—imagine have 1,000, 10,000, or even 1,000,000 web clients trying to make requests to the same web server. Yikes!

![Server under load](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/p5eds26t58j4ldaugb6w.png)

While it’s out-of-scope for this edition of the newsletter, one important consideration for web servers is scaling. We’ll discuss scaling in its own edition of the newsletter, but in short you will often need to find a way to scale your web service to accommodate varying amounts of traffic. This can be done using vertical scaling (making your server more powerful) or horizontal scaling (adding more servers to handle the load).

## Concluding thoughts

In the next could editions of the newsletter, we’re going to focus in on two of the technologies mentioned in this article that enable client-server communication: HTTP (the message request format) and DNS (how clients locate servers). Understanding web servers also unlocks a lot of related technologies we can look at—server-side programming, file storage, and databases, to name a few!

---

This article is part of the How the Web Works series I'm running over on Substack! If you're interested in following along, check it out here:

https://howthewebworks.substack.com