Before beginning there are just a few terms that I use throughout that would be helpful to have defined right off the bat.
Protocol — Set of rules
Client — Think of it as your home or office computer
Server — Where information is stored
This article is going to go over how your computer (or client) communicates with a server (i.e. a web page).
First off, let’s break down this one piece of communication into four layers of communication (we’re going to focus just on the Internet Protocol Suite). Now imagine this communication being a relay race, with each layer of communication being one of four runners.
The runners are focusing on passing a single baton (request/data) from the start of the race, to the end of the race. This is like clicking any link, or sending an iMessage, or playing a song on Spotify.
Let’s introduce another aspect of passing the baton. Each runner now has a sticker associated with them. The runner will place a sticker on the top of the baton. Right before a runner passes the baton they will put a sticker on top of the previous sticker (So only the top sticker is visible), and all the stickers underneath, just become a part of the baton.
When someone passes you the baton, you can see all the information that the sticker has on it, and then you replace it with your own, and pass it on the next runner, and so on. The information on the sticker of the previous runner is a header. This just gives us additional information on how to process the data (or the baton). Maybe the sticker says the runner has to run backwards, or on their hands, or switch it for a wooden baton, and so on. The runner only sees the one sticker and the baton (or the header and the data). So each runner isn’t concerned at all about the stickers that are covered up, much like the current layer isn’t concerned about the headers that are now covered up.
The first runner is the Application layer, we can call them Helen the Typical Passer (or HTTP), this is where the race begins (or the request begins).
Helen takes pride in being the most well known runner, and she runs in the majority of these relays. She’s been around since the dawn of relays, but every now and again she makes improvements on her running strategy. We’ve probably seen her initials many places around the internet. These 4 letters can also be a part of a web address (or URL) such as http://www.google.com and sometimes we see http://www.google.com/search?q=dogs. A URL seems confusing but can be broken down quite easily.
http — What set of rules to use (I’m passing the baton with my right hand, so I let the next runner know this so they can be ready for that)
www.google.com — The host, we can also think of it as the server, where our requests are going (This is where the relay is being hosted, i.e. at the Rec Center).
/search — The path to take once we get to the host (or what track at the Rec Center we’re running on).
?q=dogs — You can think of the
q as a question and the response is dogs. The
? indicates a start of a question (or query), this means it will send data to google and that data is that
dogs is the answer to
q. In this case, this is what it looks like when you google dogs.
The second runner is the Transport Layer, we’ll call them The Confident Passer (or TCP).
Let’s dive into why this runner is so confident. TCP is so confident that they love going over to the goal-line referee and shaking their hand and introducing themselves before the relay starts. TCP not only wants to shake the ref’s hand once, but THREE times. TCP is more than confident that the ref now knows TCP and TCP now knows the ref, they’ve established a connection. We’ll call this the TCP Handshake. If the ref won’t shake three times, TCP cancels the race.
Let’s take a quick detour to the postal service to explain this next part in detail.
How do we know the mail that we’re receiving is safe? When physical mail moves across from the US to the Canadian border we have customs who have their set of rules to check to see if the package is safe to continue on its route. For each checkpoint (in this case, Country) we do another security check to make sure that it’s safe. If it’s deemed unsafe, it’s thrown out, customs does not contact the sender or the receiver of the mail of it’s unsafe (unless it’s a threat to national security!) Checksums are the internet’s way of implementing checkpoints to check if the data wasn’t tampered with. The amount of checksums and where they are along the journey depend on the protocols that you’re using, and in the same vein, if the data is corrupt, the protocols discard it, without contacting the sender or receiver.
What if the mail is something that you’re expecting? You want to make sure that there’s a system in place to make sure that you receive what you’re expecting. It works in a similar way to ordering something off of Amazon.
Let’s say you went to amazon.com and ordered the first Lord of the Rings book (Request). You would receive an email (Acknowledgement of Request) of your order and a promise that it will get delivered in X amount of time. When your book arrives, the mailman will send an acknowledgement to Amazon that the book had arrived and no further action is needed on either side (Final Acknowledgement).
This is the three-way handshake (or TCP Handshake) we saw earlier. And to break it down in more technical terms:
- we have a request to a server (client => server)
- an acknowledgement of the request from a server (server => client)
- and a final acknowledgement to the server (client => server)
This is why TCP is so confident. It’s a fool-proof way of ensuring data gets to where it needs to go, but it doesn’t stop there, TCP also guarantees that you get your items in order.
After receiving the first book, you want to order the next two. This means you have to wait until receiving the first book before ordering the next two. If there’s an issue with receiving the first book (it gets lost in transit) then this delays ordering the next two books. This describes Head-of-Line (HOL blocking).
And to go further, the mailbox is how much mail you can receive at once (this is the buffer). In this scenario, if your mailbox doesn’t have room for the incoming mail, the mailman just tosses it in the garbage. In this case we want to anticipate how much mail we’ll be receiving so it won’t overflow. If the holidays are coming up, we’d want to temporarily install a larger mailbox (increasing our buffer size), switching back to our original size after we receive all the presents we’re waiting for. This information of the buffer size would be carried on the header. Remember, the header is the sticker on the baton that is passed onto the next runner.
Congestion avoidance is achieved by looking at how much mail is thrown out to determine when to get a bigger mailbox. Networks do the same, but with how much data is lost to determine when to change the size of the buffer.
Going back to our relay, sometimes we don’t want to use TCP as the second runner, sometimes we want to use the Uncomfortably Direct Passer (UDP). She doesn’t waste any time getting to know the ref, she doesn’t establish any connection, she just starts running as soon as possible. She’s unreliable, but she makes up for it in SPEED and FLEXIBILITY. She will go shake hands with the ref if you really want her to, and she can do most things that TCP can do, she just doesn’t default to that.
To explore why UDP is so flexible take the example of ordering the Lord of the Rings trilogy off Amazon.
Ordering the books one at a time isn’t efficient if you want to know how the story ends! So instead we can order the entire Lord of the Rings trilogy at once, and Amazon will ship out the books as they are available (chances are they’ll all be available at once). But if the first book is sold out, it will ship the last two and ship the first one once they get it in stock. We know not to start reading the books until we get the first one, because these books are ordered.
This means that we don’t get any Head-of-Line Blocking, but in addition we also have no flow control (if our mailbox gets full, there’s no means to change the size of it) and no reliability that the books actually arrived since there are no more Handshake Acknowledgements.
In more concrete terms:
- TCP, in all its reliability and security, is usually what we see when we browse the internet, we want every item on the page to be loaded.
- UDP, in all its speed and flexibility, is usually what see with video calling. We want it to be quick and it’s not so important if the video skips for half a second.
The third runner is the Internet Layer, we’ll call them International Passer (or IP).
So far, we have Hal the Typical Passer (HTTP), handing over the baton to The Confident Passer (TCP), handing over the baton to International Passer (IP). This is one exhausting track meet, are you still with us?
Mr. International Passer is so international because he’s concerned about where he’s going. He’ll take in all the information off the sticker from TCP and then place his sticker on the baton right before passing it on. He is the one that holds the information that says where the starting line (source address) was, and where the finishing line (destination address) is.
Depending on where the relay is happening, the starting and finishing lines are in different locations. This means that your starting line changes depending on where the relay is. Computers work in the same way, they are assigned an address when you join a network (or the relay). If it’s in New York, you’d have a New York address, if it’s in Toronto, you’d have a Toronto address.
Our computers are given an address each time we connect to a network. We call this the IP Address.
The source and destination addresses are just IP addresses.
But on our computer there are multiple conversations happening at once (i.e. scrolling Instagram, listening to Spotify, sending an iMessage, etc). So how can we be sure that the Spotify messages are going to Spotify and not Instagram? This one address isn’t going to cut it.
Ok, ok, so our computers are more like apartment buildings and not a house. We have a unit number within an address.
If we think back to our postal system, we’re able to send and receive multiple pieces of mail addressed to the same location. The postal company receives all this mail for you and sends it all to the building address (multiplexing), the concierge will then sort through and make sure the mail goes to the appropriate door (demultiplexing). So far we just have the one identifier, an IP address, so what’s the second identifier? How do we know which unit number to go to? The answer: a port.
Each alone does not give you the info that you need, so you can think of the combined IP and port number as the full street address with a unit number (or, a socket).
The internet is just a collection of billions of these apartments, organized into networks (we can think of this as a city, or a neighbourhood). It’s a world of neighbourhoods.
So, Mr. International Passer, is able to communicate anywhere in the world, that’s what makes him so international.
The fourth and last runner is the Link Layer, we’ll call them Ether Nyet (or Ethernet).
Ether Nyet is the last runner, and because of this, she’s the only one that has direct contact with the finish line. And as you might have been able to tell from her name, Nyet (Russian for “no”) she’s not willing to let anything get by without translating it first.
So when she crosses the finish line, she makes sure to explain what happened the entire race with each baton pass to her family waiting for her at the finish line because they weren’t able to understand the English announcers. She translates all the data to something everyone can understand, so the family can go home and explain to everyone what happened. She also gives the winning baton with all its stickers to her family to bring home to show off to all the relatives.
This layer is only concerned about bits (basically just 1's and 0's) just like how Nyet’s family was only concerned about Russian. So it needs to translate the information that IP passes it so it can be transported to where it needs to go.
The route Nyet’s family takes is dependent on the infrastructure that exists, do they take a bus? A car? A plane? A boat? Each of these forms of travel have different purposes. Generally we’d take a car — plane — car to home if we’re going very long distances. The same thing happens with the internet, for example, we could take electricity — radio waves — light waves — radio waves — electricity. The internet exists in a very physical way, and to get communication across the ocean we have fibre optic cables (to transfer data in the form of light) that sit on the ocean bed floor that transfer the data that Ether Nyet translated.
And finally they reach the destination peel off all the baton stickers and show their family.
Let’s recap quickly, because there are a lot of moving parts.
- The race starts when we make a request.
- HTTP is first up, she places her sticker and passes the baton to TCP.
- TCP made sure to shake the ref’s hand and then places his sticker and passes the baton onto Mr IP.
- IP makes sure that his sticker says where they’re going and where they came from and passes the baton to Ethernet
- Ethernet translates the information so the data can get to where it needs to go.
This process is repeated for every little aspect on a web page, it could be tens or hundreds, depending on the complexity of the web page.
And at the end of all that, our four runners, exhausted, never let you know that, because well, they’re professionals.
NOTE: This of course is a simplified version of how everything functions, I mostly omitted the use of jargon and computer related terms so it would be easily understood by those who may not have background knowledge coming into this.