Part I · Chapter 1 · The Diagram · lesson 2
What is actually running when a page loads
14 min
Part I · Chapter 1 · The Diagram · lesson 2
14 min
You type an address, press return, and a page appears. Somewhere between those two events a program that was already running received your request and decided what to send back.
That program is the server. Not the machine it runs on, not the company that owns the machine, not the address you typed — a program, running, waiting. Everything else in this subject is a consequence of that one fact, and most of the confusion beginners have about systems comes from the word "server" meaning three different things in ordinary conversation.
This lesson is about what is actually happening while nothing appears to be happening.
Predict
A process. A running program with its own memory. You can list them, you can stop them, and when one stops, everything it was holding in memory is gone. A machine runs many processes at once — your app server, the database, and a few dozen pieces of the operating system.
A port. A number that says which program on the machine a connection is meant for. One machine has one address and tens of thousands of ports, which is how it can run a web server and a database at the same time without them getting each other's mail.
A socket. One open conversation. When a browser connects, a socket exists for as long as that conversation does. Thousands of them can be open at once, and each one costs a little memory whether or not anything is being said.
A request and a response. The browser sends a few lines of text saying what it wants. The program sends back a few lines saying what happened, then the content. That is the whole protocol at this level, and you can read it with your own eyes.
The thing to take from that list: a server is not a special kind of software. It is an ordinary program whose main loop happens to be "wait for a connection, read what it says, work out the answer, write it back, wait again". You could write one this afternoon, and that is not a figure of speech — in most languages it is about twenty lines.
Because the word means three things, the complaint means three things, and they have nothing in common except the word.
The program is slow. It is doing too much work per request, or it is waiting on something else — a database, another service, a file. This is by far the most common case and it is the one the rest of this subject spends most of its time on.
The machine is overloaded. The program is fine and there is not enough processor, memory or disk to go round, possibly because something else on the same machine is eating it.
The network between you and it is slow. Nothing is wrong with either the program or the machine. The bytes are taking a long time to travel, or a long time to be allowed to start travelling.
A beginner reaches for the second. It is the rarest of the three. The habit worth building now, before you have any measuring tools at all, is to ask which of these three somebody means before agreeing that something must be done about it.
Check
The fastest way to stop treating a server as furniture is to run one and look at it. Three steps, no framework and no cloud account.
Run the smallest server there is. In a directory with a file in it,
python3 -m http.server 8000 starts a real web server on port 8000. It is a
program, it is now waiting, and your browser can talk to it at
http://localhost:8000.
Watch the requests arrive. It prints a line for each one. Reload the page and the line appears as you press the key. That printed line is the moment the kernel woke the process up.
Look at the request itself. curl -v http://localhost:8000 prints the
lines your browser normally sends and receives on your behalf. The method, the
path, the status, the headers. There is no magic layer underneath this; it is
text going down a socket.
Then stop the program and reload. The browser says it cannot connect — not "page not found", which would be the server answering. Nobody is listening on that port any more. That distinction between "nothing is there" and "something is there and says no" will save you an hour at some point.
The condition under which this lesson's picture is wrong: when the page is served entirely from files, with no program of yours running anywhere.
A great many sites are a folder of files handed to a content delivery network, and the answer comes back from a machine near the reader without any code of yours executing. There is still a program running — somebody else's, on somebody else's machine — but there is no app server in your diagram, no database behind it, and most of this subject's questions do not arise.
This is worth knowing for two reasons. It is the right architecture far more often than people building their first product assume. And when it is the right one, almost every box on the whiteboard from lesson one disappears, which is the cheapest possible version of the argument the rest of this subject makes slowly and with arithmetic.