A Deep Dive on Networking

This past week, I’ve had to refresh myself on my networking and cybersecurity knowledge. I figure that this makes for a perfect opportunity to do an explainer post on each topic. This week, we’ll be starting with networking…

The Absolute Fundamentals

The atomic unit of networking is the packet.

A packet is a chunk of information sent from one computer to another. It consists of two things: a header (which tells the packet where it needs to go and what it needs to do) and the data itself. Usually packets are not very big — in other words, if you are downloading a 3 GB file, you are not going to get it in a single 3 GB packet, but rather an assortment of much smaller packets.

It’s easy to make an analogy that networking is like physical mail, since that’s indeed what the system is based on. IP addresses are like mailing addresses, and are where the packets get sent. A typical IP address might look something like:

203.82.12.2:8888/24

This seems really complicated, but in actuality its as easy to read as a normal mailing address. The easiest place to start is with the back: the “/24” is called a subnet mask, and tells us which part of the address is the network versus the actual device. As I’m sure you know, a single network can have a ton of devices attached to it — this mask helps us know that the first 24 bits of the IP address (for simplicity’s sake, the first three dotted sections of the address) are the network. So let’s say you’re downloading something to your laptop from your home wifi — the “203.82.12” is the address to your wifi, and the “.2” at the end says its your laptop.

But wait! What’s the “:8888” for, then? Well, as it turns out, just having the wifi and laptop isn’t enough information. Within the laptop, you might be receiving packets both for streaming music to Spotify, as well as the download from your browser. How does the packet not get confused about which app to go to?

With ports, of course!

That’s what this 8888 is at the end — this signifies that the download needs to go specifically to your browser, which is claiming the 8888 port on your device. Spotify might be claiming something else, such as port 2323, and so the packet knows not to go there.

Further Into IP

Within the range of IP addresses, there are two types: public and private.

If you are a person at home lounging around on your personal wifi, you probably don’t care too much about private IPs. Private IPs help route packets between devices on the same network. A better example might be within a big corporation — you might have information stored in a server downstairs, and need to access it using your work computer. In that case, since nothing is leaving the network, you simply use private addresses — something managed by the IT department using something called a DHCP.

Public IPs are where things get interesting.

A Public IP is used when communicating between different networks — in other words, the Internet! Both individual people as well as large corporations have IP addresses on the Internet. For example, when you go to google.com, you are establishing a connection between Google’s public IP address, and your home wifi’s public IP address (more on why Google’s IP doesn’t look like a jumbled mess of numbers later…).

Now, here’s an interesting conundrum. Within the scope of addresses, you can never have two of the same IP. This makes logical sense — it would be very confusing to a postal worker if there were two identical addresses that happened to go to different places. In addition, there are only so many combinations you can make an IP. The IP I mentioned to you earlier can only have four dotted sections, and each dotted section can only go up to the number 255 [1]. This gives us a few billion or so different combinations for what we can make our IP.

For Private IP, this is a non-issue. Even the largest corporations in the world would never get close to a billion devices on a single network. Yet, when it comes to the entire world — well, we could rack up a billion devices pretty quick.

So for public IP, we’ve begun to move away from this four-section system — referred to as IPv4 — and have started to move towards a more complicated system known as IPv6. IPv6 uses a different system called hexadecimal, and while its becoming the new standard its also a bit more complicated to explain — so we (and every other networking course) stick with explaining things in terms of IPv4 [2].

Back to Packets

Now that we understand how IP addresses work, it will be much easier for me to explain packets.

As I mentioned before, packets consist of two things: headers, and data. A header is essentially the properties of the data the packet contains, and may consist of things such as:

1. The IP version its attached to (IPv4 or IPv6)
2. The Source IP Address (where the data is coming from)
3. The Destination IP Address (where the data is going)
4. The Packet Protocol it is using
5. The Time To Live (TTL)
6. The Packet Data Type

Now, those last three header properties should rightfully interest you. TTL is something we’ll get to in the next section, but let’s dive into packet protocols and packet data types:

A packet protocol is how data gets sent. In general, there are two protocols: TCP and UDP. These sound very complex and intimidating, but they are actually the simplest networking concepts to understand! Basically, TCP means that we verify first, send second. That is, we make sure there’s a stable connection between the two IPs, and then go off to send the data. On the other hand, UDP is send first, verify second — we just go out and send the data, and if there’s a stable connection at the end its wonderful to hear (but not necessary for our cause).

As you can imagine, TCP is much slower than UDP — but its also more secure, in that we know our data will make it to the other side. The best way to think of TCP versus UDP is with the movie example:

If we’re streaming a movie, we can afford to use UDP. The movie might buffer or glitch here and there, but its faster than sending over the entire movie to the user’s local drive (it also helps deter pirating). But if we’re downloading a movie, we need the entire file. A single chunk of a movie missing from our local data means that at best we straight up cannot watch a chunk of the film, and at worst the entire film is corrupted and unviewable. In the UDP case, this isn’t important since there’s an entire uncorrupt copy of the movie at the source IP — we don’t get that luxury here, so we need TCP.

Then there’s packet data types. We’ve actually already covered one of these — download data. Streaming data might be another one. If you’re just trying to load a webpage, it’s called HTTP, and if you’re trying to load an email its called SMTP. Pretty simple!

How Packets Get Routed

Now, if you’ve gotten this far, everything I’ve said works up to a basic understanding of how networking works. If you were just curious how networks and the internet operated, and weren’t trying to use it for a job or any technical purpose, congrats! You’ve graduated. You’re free to move on to where you please.

Of course, what I’ve told you isn’t the full story. One key element that’s been missing is how packets get to one place or another. I told you about the source and the destination — I told you how they find out where they need to be — but I did not tell you how they then use that information to get to where they need to go.

Welcome to routing.

In your home, your ISP set you up with something called a router. A router does two things. The first is that it manages what your public IP address is, which allows you to be seen and interact with the internet. The other thing is that it helps packets find you, and sends packets to where you need them to go.

The language of IP routing is something called BGP, and every router speaks it. I think the easiest way to explain routers, routing, and IP addresses is through a direct example. Let’s start with your computer:

1. You ask to download a file on your laptop.
2. Your laptop sends the packet containing your request to your router.
3. Your router sends that packet off to your ISP’s regional ASN. An ASN is where the magic happens — it’s a giant virtual switchboard containing links to the billions of other public IP addresses in the world, usually hosted in large datacenters run by your ISP. These ASNs are regional — this means that if you live in California and send a request to Google, it will probably just go to the ISP’s US West ASN and immediately go to Google afterwards. But if you live in Sweden, it might go to the Scandinavian ASN first, then cross the pond over into the US East ASN, and finally to the US West ASN [3].
4. After it reaches its destination ASN, it sends the packet to the company your downloading from’s router — usually in their data center.
5. The data center receives the request, and sends a response back.

Now, there’s a term I mentioned last section — Time to Live, or TTL. This term actually has a big importance in BGP. You see, the entire point of BGP is to solve an old issue with IP routing: that of the default route. Back when you used to do IP routing, you would set up a default route such that, if a packet was partially missing information (such as a port or device), your packet would still be sent somewhere where it could be retrieved. While this was convenient, it was also a massive security flaw — all you had to do is know the network IP, send a toxic payload in its direction, and it would infect whatever server took in the default route packets.

So, how do you fix this problem? Easy — make it so that you can’t send to a default route anymore.

In addition to various other optimizations and security improvements, BGP’s fundamental change was that instead of sending vague packets to a default route, it would simply drop them. This meant that there was sometimes more data loss, but there was no longer an obvious loophole. BGP is also policy-based, meaning that instead of just trying to find the fastest possible route, it will conform to whatever policies happened to be set up by the local router or ASN in order to enforce custom security protocols that they might have.

How does this tie into TTL? Well, as you might have guessed, “Time to Live” is talking about the packet — after a certain amount of hopping between servers, the packet will automatically be dropped, and the logic behind such a move is the same as that of BGP.

Layers of the Internet

I want to end on talking about the layer model of networking. If you’ve done any serious studying on networking before, you’ve probably heard the layer model come up. Fortunately for us, all the important parts of the layer model we’ve already talked about, so this should come as second-nature to you.

There are two types of layer models: The TCP Model, and the OSI Model. The TCP Model (named that way since TCP used to be the only way to get packets from one place to another) is the model computers actually use, while the OSI Model is what we teach. There is zero difference between the two, other than that the OSI Model is a little more detailed and thus serves better as a teaching tool.

The OSI Model has seven layers, starting from the closest to the source to the most far away.

1. Layer 1, Physical – The physical hardware attached to the network processing. A good example might be your desktop, the ethernet cable that connects your desktop to your router, and the router itself.
2. Layer 2, Data Link – This is the local network content. This is mostly driven by switches, which are basically just routers but for local/private IPs only.
3. Layer 3, Network – This is where all the IP magic happens — whether it be a public or private IP.
4. Layer 4, Transport – The transport method, which as we’ve learned is usually either TCP or UDP.
5. Layer 5, Session – The method in which two IPs “handshake”, or greet each other. We didn’t talk about this much here since we’re saving it for cybersecurity.
6. Layer 6, Presentation – This will also be discussed during the cybersecurity section.
7. Layer 7, Application – This is probably the layer you interact with the most. It’s exactly how it sounds: apps like your browser, your video streaming service, etc. Most fancy tech networking tools, such as networking virtualization or cloud security, also work on the Layer 7 level — even if they’re emulating something earlier down the layer chain.

And that’s it! In case you’re curious, the TCP model is just four layers – Link (Which combines OSI 1+2), Network, Transport, and Application. But like I said, behind the scenes its doing the full 7-layer shebang.

Other Curiosities

There are two things that I think are vital to the discussion of networking, but I wasn’t able to fit neatly into my conversation:

The first is DNS. I talked to you about how, when you’re computer interacts with Google, it’s connecting straight to Google’s public IP — that’s true. But you might be wondering why you type in “google.com” into your web browser instead of a complicated IP string.

Very early on people realized it was a pain in the ass to remember public IPs, and they thought it might make more sense to give them real “human” names. So the domain naming service, or DNS, was born. Essentially DNS is a system that lives in all the same places that the Internet lives (i.e. routers and ASNs) where, if you give it a name like “google.com” instead of a public IP, it can read the Big Book O’ DNS to find that google.com actually means the public IP of Google. And every time you buy a domain name, you are asking your domain name registrar (Namecheap, WordPress, etc.) to go write in the Big Book O’ DNS (this is actually a decentralized database, just so we’re clear) that your new domain name should connect to your server’s IP, and so now all routers and ASNs know where to go.

The second topic was remote access methods. This is a weird one. Technically it is more of a cybersecurity thing, but it really doesn’t have anything to do with cybersecurity. It’s also important enough that I feel compelled to mention it somewhere and not just drop it out of the curriculum. So I’ve decided to add it here.

A remote access method is exactly what it sounds like: it is a remote way to access either 1) a device that’s far away, or 2) the internet through an intermediary source. There are three major remote access methods: SSH and RDP for devices, and VPN for internet.

SSH and RDP are very easy to get at a basic level. If you SSH into a device, you gain command-line access to it. So you can’t open up a web browser or anything like that, but you can view files, move them, copy them over, delete them, etc. You might be able to see why, based on that description, this is very much a cybersecurity issue.

RDP is the exact same, but now you can use the desktop’s UI — in other words, you can open the web browser. It is very clunky, very insecure, only works with certain OSes, and in general is rarely if ever used. IT managers usually prefer to just use third-party virtualization software, such as the ones provided by Oracle, Microsoft, or VMware.

Then there’s VPN. You’ve most certainly heard the word VPN, likely due to all their advertisements, and could probably surmise that they give you a more private connection and allow you to watch Netflix Canada. I’m sorry to tell you this, but in reality they do neither of these things.

All VPNs do is provide a way to access the internet without letting your ISP see what you’re accessing. The ISP sees you connect to a VPN, but then the VPN spits out a massive amount of connections going all over the place, and they can’t connect that to you.

This might seem private, but there’s two issues. The first is that the ISP does see you connect to the VPN — and if you’re living in some dictatorship dystopia, that’s all the info the ISP needs to rat you out to the police. Secondly, ISPs are much, much bigger than VPNs, and usually just pay the VPNs to tell them your traffic anyway, so neither of them get in trouble if you do something illegal. Some VPNs will just report what you do anyways, which sort of ruins the whole point of having a VPN.

The “viewing other country’s Netflix” thing is a little more grounded in reality, but alas this is also not VPN. The process for this is a completely different tool known as a web proxy — something we cover in the cybersecurity section — and it is something which VPN companies use, but is not something tied to the VPN itself.

In order to talk about what the best use-case for a VPN is, we actually need to think of it from the perspective of probably the least private thing in the world: your employer’s wifi network.

So a VPN can be used to connect to the internet, but it can also be used to connect to tools that you would normally not have access to on the internet. Some companies make you connect to their VPN in order to use a company app or software — allowing that app to never actually connect with the internet, where it is more likely to be hacked. This is the use case for 99% of real VPNs.

And so, this ends our journey into networking. Next week, we’ll be covering cybersecurity and topics such as firewalls, SSL/TLS, proxies, zero-days, and more. See you then!

[Image omitted]

[1] – This is due to how IP addresses are defined, which is using something called “bits”. Each dotted section represents 8 bits, so we have 32 bits in total. Using 8 computer bits (essentially a chunk of binary), you can represent the numbers 0 through 255 — 256 numbers in total.

[2] – That being said, if you understand the fact that IP is based on bits, its not actually that much more complicated to understand. Hexadecimals simply give us more bits — we can start doing subnet masks up to 48 and 64 bits, for example. The only problem is you cannot visibly see what part is the network and what part is the device, unlike with IPv4. Same thing is going on in IPv6, though.

[3] – Now, Google is an omega giant company, and therefore probably has a direct connection to every ASN on Earth. But I’ve altered it for the sake of the example.