Clients and Servers
The web, and thereby the human resistance plans, has always been based on the client/server model. In this model, you have one centralized store of knowledge (the server)—much like the commander of your human resistance cell—and many different computers asking that server for information, like you and your apocalyptic colleagues asking the commander where you should deploy or what the next step in the zombie offensive is.
Clients are the computers you’re familiar with. They’re only connected to the Internet when they need to be and typically have user input devices like a keyboard, mouse, or karaoke microphone (oh, wait, that’s just me). They also run web browser software, like Firefox, Safari, Chrome, or Edge, and send out requests (e.g., Dear Google, please show me cute pictures of kittens).
Servers are usually higher-powered machines (those with more memory, processing power, storage, etc.) and are always connected to the Internet. They run server software like Apache, IIS, or NGINX, and handle requests (e.g., Here you go, dear user. Have thousands of cute pictures of kittens. I hope the cuteness does not make your face explode—unless you are a zombie, and then I hope it does).
The server is always on, always connected to clients, and always ready to answer their questions or requests. Some questions you ask your commander will require thought (like should we attack the zombie nest from the north or the south), and some don’t (should I kick the zombie currently attacking me? Yes, use a <footer> tag for extra damage). Similarly, a server may directly hand you a web file, or it may take time to process your request. Typically, with HTML, CSS, and JavaScript pages it’s a straight hand back, but with PHP, ASP, server-side JavaScript, or other scripting languages, the server may have to build the HTML page before it hands it back. In general, the server, no matter what other software is running, will hand your computer (the client) HTML, CSS, and/or JavaScript files (plus media files, like images, etc.). For instance, by the time the server sends to the client a PHP page, it has no PHP code left. It has all been converted to HTML. It’s the converted HTML that will be acted on by the CSS and JavaScript. No matter what language you use to build the back end of the site, solid HTML and CSS skills plus knowledge of JavaScript will always be helpful as you problem-solve how the site was outputted or how the HTML elements, CSS, and JavaScript interact.
Protocols
While the following is an oversimplification of what happens, it should give you a basis for understanding how a network request works.
TCP/IP are two protocols the Internet is built on. TCP/IP stands for Transmission Control Protocol/Internet Protocol.
The IP protocol is similar to a mailing address or the location of a particular human resistance cell. If two human resistance cells go by the same name, but one is located in a former department store and one hides out in the remains of a jungle mini-golf course, you can differentiate them by location and, thus, send a message to the correct human resistance cell (computer). The IP address is a series of numbers (and sometimes letters) that uniquely identifies a computer on the Internet.
Like an apartment building where people move in and out, sometimes an address will get you to a different person than you expect or intended to reach. Sometimes that’s because the person or website moved, and sometimes it’s because the IP address lease expired or was reused or sold or what have you. What happened to the IP address doesn’t matter as much as knowing where the person or site you were trying to communicate with is. On top of that, while the series of numbers and letters is easy for computers to manipulate, it’s not easy for humans to remember. I might remember the IP address for undead.institute (which as of this writing is 35.224.226.126) because I use it often, but you—whom I’d want to go there and look up resources and play games etc.—almost certainly would never remember it. So, the people who built the Internet came up with handy things called domain names. They must still be unique, but they are far easier to remember, since they are based on words and sounds users are more familiar with (at least for English speakers) and feel less arbitrary to non-technical people.
The connection between a client and a server over the Internet isn’t like a single pipe stretching between two human resistance cells. It’s more like taking a single message and cutting it into sections (packets in the networking world) and sending each section with a different messenger. Each messenger can take a different route in the hope that if one route is blocked by a horde or zombie nest, the other messengers can still get through. Each section of the message also contains information about which resistance cell the message is from, how many sections the message has, a bit of info called a checksum that can tell you if zombies or zombie sympathizers have tampered with the content of the section (it uses an algorithm that takes the message data as an input and spits out a code that would be different if the message was messed with or damaged in transit). If a checksum doesn’t match or a section is missing, the receiving cell (server) sends a messenger back asking for replacements. This is the TCP of the TCP/IP protocol the network is built on.
IP is where the message or packet comes from and goes to. TCP is how the message gets there and how we know if the arriving message is the same as what was sent.