Published: 12th August 2023
Last updated: 12th August 2023
1
Abstraction and models are tricky when you're trying to wrap your head around them. So here's how I came to understand it. I'll start with those two words.
A model is a representation of something, stripped down to its essential details. Think of a lego house. It's smaller, doesn't have electricity, but it does have all the essential features of a house. It has doors, windows, made of bricks, etc. It allows you to simplify the idea of a house so you can inspect it.
A model is an abstraction of a real thing: the lego house is an abstraction of a real house.
The same applies for things like OSI Model and TCP/IP stack. They are models for how applications can communicate.
TCP/IP is a model that has four layers of abstraction, working from the most logical at the top (that is, the furthest away from a physical thing you can see or hold) to the lowest (the closest to a physical thing you can see and hold.)
We'll take a whirlwind tour of the layers, starting at the bottom and work our way up - then back down, encapsulating a request from the application layer.
We'll start at the bottom, most real-world of the stack - the Network Access Layer or Link Layer.
This is a group of protocols and standards which define how light pulses along fibre optic lines, or specifies how much voltage constitutes a bit in a particulare ethernet cable. Notice that it doesn't give a shit about your IP address, gaming latency, or request to pornub. It's a group of protocols and standards that only cares to describe how routers should interact with those pulses, etc. and how to analyse them and route them across local networks.
We've moved up a layer of the model, so we're going to throw away details now. We don't need to care about how light or voltages work at this layer. Now we're concerned about how to move data around bigger networks and start getting that data to machines. This layer invents things like IP addresses and ARP. Just a group of protocols for routing data across networks, and less about how you physically do it.
Again, moving up another layer of the model, so we throw away more details. Now we care less about how to move data across large networks, and more about transmission of data itself. Note that prior to now, we cared about how to move arbitrary payloads across networks. Now we don't care about those networks, but more about how those payloads look and are written onto the network. We're still moving away from real world stuff, and into logical, abstract, imaginative ideas that are intangible.
The final layer, the most abstract one is the application layer. This is where we deal with things like HTTP, DNS, FTP. The common protocols. They are the most logical, abstract ones because you can't point at an HTTP request "in reality." You can point at the voltages or pulses (I guess) but not the request.
Each layer includes protocols about how to interface to the layer above and below it, but no further. So how to get from the Application Layer to the Transport Layer.
Starting with Application Layer. You can draft an HTTP request, that's great - but it won't do anything if you don't know how to send it reliably across a network. So you take that HTTP request and wrap it up in a TCP request. But that won't get it across a network, so you wrap that [TCP[HTTP]] request up and put it in an IP request. [IP[TCP[HTTP]]] is good but you still aren't getting it across the lowest layer, which is the link layer - until you wrap it up again and transmit it using some defined standard for communication.
This is a fantastic diagram showing the encapsulation of each protocol, by each layer of the model.
This is simplified and some purists will argue (rightly) with some of the generous interpretations here. But if you made it this far and you understand it, then you are in a great place to get into the details. Go play with Wireshark and see that encapsulation in action.
Seen something in your logs?