The simplest version of the internet
In a recent interview for an engineering position I was asked a very broad-reaching question: how does the internet work? There are many different answers to this question, depending on how granular you’d like to get, so I wanted to share the simplest version I can.
At its most basic, the internet would consist of two computers: a client, and a server. Let’s say we’re using a cell phone to check the menu at a restaurant — in this example, the cell phone would be the client, and the server would be whatever computer is hosting the menu. Even in this very simple example, there are a handful of steps: you enter a URL in your phone’s browser, the browser looks up the IP address for the domain name, the browser sends an HTTP request, and then the server sends back an HTTP response. In most cases, the browser would then send additional requests for objects in HTML, like image media, CSS, and JavaScript through the same initial steps.
To take a closer look at these steps, we should talk about routers. In our example, when we visit the restaurant’s website on our phone, we’re requesting information that is delivered by routers. The core of the internet are routers that move information in packets. If the information we’re interested in is especially large, it would be broken up into several packets. The routers each have a table of numbers to outbound links, which are used to route the packages based on the destination address. You might imagine a packet of information like a letter in an envelope, with a destination address and a return address. When these packets go on their journey, they make several stops, and each subjourney is called a hop. A packet would hop from your laptop over your wifi to a modem box, and then from there to Verizon or AT&T’s bigger router, and then further out in the world.
So far this might not be that surprising — information is stored somewhere and retrieved when it’s requested. The model for this system is called TC/ICP (Transport Control Protocol / Internet Protocol), which is made up of four layers: Link, Internetwork, Transport, and Application.
The Link layer is responsible for connecting a computer to its local network. In our example, the cell phone is the computer and the local network would be the cell network or WiFi. The data moves in a single hop from the cell phone to its first router, which is also called a gateway or a base station. Any base station uses link layer technology to connect to the next router. In our example, that means the radio frequencies used to transmit data and how that data will be encoded in the radio signal. Since every computer receives packets broadcasted by the station and by nearby computers, the packet has information specific to the computer’s own wifi radio — what’s called a MAC address. Your computer’s MAC address is unique, and remains the same for the life of the radio.
Now that our phone has made it to the base station, the next layer after Link is Internetwork. Our packet is in the router and includes attributes like its source address and its destination address (like the return address and destination address on an envelope). These attributes are both called IP addresses and are given to every computer based on where the computer is connected to the internet. If you drive a town over, your cell phone’s IP address would change, but the MAC address will always be the same.
IP addressing allows for routers to build routing tables to get packets to their correct destinations, but because information is broken up into packets they may arrive out of order, or even mishandled and lost. For example, a loop can form where information is passed in a circle and never arrives at its destination, so to solve this problem packets have another attribute called TTL or Time To Live. This number counts down with every hop, and the packet expires after the countdown reaches zero.
With the risk of our packets arriving out of order or even dying in transit, we’ve arrived at the Transport layer. The transport layer solves these two problems by interpreting each packet’s “header”, which includes data about the overall message, including its total length or the number of packets. In the destination computer, a message is reconstructed using these attributes and it can be determined whether it has received all of the packets and which are missing. While waiting for the destination computer to send acknowledgement that the packet has been received, the source computer will temporarily store a copy of each of the parts of the original message that have been sent so far. This means the source computer will send information, wait for acknowledgement from the destination computer, and then continue to send packets.
This brings us to the Application layer. Web applications can broadly be split into two categories: clients and servers. Both need a protocol that describes how they will exchange messages, and HTTPS (hyper text transfer protocol secure) is one such protocol. HTTPS works through requests — we made a request on our phone when we entered the URL of the restaurant menu, and the server that holds the menu made a request back. The most common request header (and the one happening here) is GET, which displays information, but others like PUT and PATCH modify information and DELETE deletes a specific resource. These request headers are sometimes referred to as HTTP verbs. Once your browser begins rendering the HTML, it places additional requests for media like CSS, JavaScript, and images. Each request follows the same request and response cycle, often to different destination addresses — for example, images might be hosted on a separate server than fonts, and so on.
As complex as this simple explanation may be, there’s always more complexity if you’re interested (for example, look into encryption with HTTPS or into the OSI / Open System Interconnection model, an alternate network design model to TCP/IP). Broadly, this explanation should at least show the underlying pattern at play whenever you open a browser on your phone or computer.
