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:
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.
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!
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:
Top comments (0)