Interesting internet networking concepts. Part One
I recently did a deep dive on computer networking and the internet, and I found some of these concepts to be really interesting. If you’ve been a developer for a while, but never really looked into the networking stack, I’d really encourage you to spend a little time hoking around to see how things work. Here are some of the more interesting concepts I really enjoyed:
- Internet Architecture
- Addresses — CIDR
- What’s IPv6?
- DNS
Internet Architecture
How does the internet actually work? Admittedly, I was totally ignorant to how information moves around, to me it was just “well… it’s all connected, and in the middle there’s… magic. You pay your Internet Service Provider and they give you the internet, right?”
So it was super interesting to find out how this all works, by learning a little history. This all started in academic settings, where computers got a lot of their first practical applications. If you’ve got 2 machines you want to communicate with one another, you can take a hard-drive or USB and copy data from one machine, then it can traverse over the “sneaker-net”, by walking it to the other machine and plugging it in*. Not much fun. For small amounts of data, we can send it over a wire. Simple enough, basically like a USB with a long lead to another computer.
This gets more interesting if you have lots of computers. With 3 computers, you’d need 3 wires to connect every computer to every other computer. But with 10 computers, you’d need 46 wires, if you wanted a direct connection between every computer. Obviously there’s a limit to how useful this model would be.
We could instead go for a hub and spoke model, which looks much simpler. The benefits should be clear - we need a lot fewer wires to make this work, and it didn’t take me 5 minutes to draw it. But what are the drawbacks? We now need another device in the middle, a device that isn’t quite a full computer, and doesn’t need to be. It’s also a single point of failure, a bottleneck. However let’s pretend that’s not a problem for now.
So in a hypothetical situation, we’ve got all the computers in a room working together nicely, and it doesn’t look like a total mess. So the next step is, how do we make that work for a whole building?
It’s a slightly larger version of the same problem. As you can see, we’ve got multiple floors, each getting scrawlier as they go down. Let’s say the person on desk A1 wants to send a message to someone on desk A2, then they go via the central connection at A, like so:
A1 > A > A2
If desk A1 someone wants to send a message to a desk on another floor, say B3, they go through the core, like so:
A1 > A > Core > B > B3
Since each machine isn’t connected to every other machine, we’re now in need of some sort of address system to pass messages around, but we’ll get to that in the CIDR section.
So far, the one company who owns the building is providing all of this networking, and footing the bill. We can send messages to and from any machine in the building, but not outside it. Let’s expand.
We could go for a fairly simple model, whereby we connect each building. For a small campus, this will work just fine.
But what if the owners of Building C are a different company? What if another building wishes to join this consortium? We’re back to the same problem as we had with many desks. Except this time, everyone isn’t next to one another, or may not have the same goals.
So we again go back to the hub and spoke model, but the hub is more interesting. We have a company, an Internet Service Provider (ISP) dedicated to being this middle man, let’s say Virgin Media. Buildings A, B and C all connect to the Virgin Media Hub in London. Now each computer on each floor of each building in London can communicate with each other. Virgin Media is also providing the same service in Leeds, so those buildings can talk to one another. Lastly, Virgin Media has connected their London and Leeds offices via 4 high speed cables — Now buildings in London and Leeds can communicate to each other! All this costs money for Virgin Media — they set up cables and maintain and repair their network, so they charge you money for this.
But one day, along comes a new entrepreneur, who thinks Virgin Media is both too slow and too expensive, so he offers a competitor service, called Community Fiber.
Now we’ve got plenty of buildings, but some can’t talk to others, because they have different ISPs. So Virgin Media and Community Fiber decide to pair up together. These deals between ISPs are normally confidential, but approximately, neither party pays a fee to pair up with the other. This allows everyone up and down the country to communicate, regardless of their ISP. Great!
The last problem for a global internet then, is quite similar to our previous problems, but on a grander scale.
The broadband providers in a given country connect to a higher tier network. There aren’t as many of these higher tier networks, but they have a much more international reach. A few examples are AT&T, Sprint, Level 3 Communications.
Again, there’s a similar problem, what if BT can get a better deal with AT&T than Sprint? Would the network fracture and only some customers be able to speak to certain countries? Similar to the previous problem, these Tier 1 networks all pair up with one another. they’re a business too, but you don’t pay them directly — your broadband provider will pay a Tier 1 network provider if it needs to use their network to deliver the traffic.
This has been over-simplified, but the idea is roughly on point. One of the more interested networks has been Google’s network.
They’ve created a premium network themselves, to traverse the globe, and offer a direct connection to this network to their cloud customers. This saves on network latency and cost, they don’t have to connect
CIDR — Classless Inter-Domain Routing
Addresses! Now that everyone’s connected, how do we direct a message to a certain location? Every end-user device on the internet needs an address so traffic can be directed to it. The address is just a number — a pattern of 32 ones and zeros (known as bits). We normally break this into 4 chunks and convert each chunk to a decimal number. Little easier to read for humans:
Some numbers coming up, but nothing complex.
There are a finite number of addresses possible, 32 options for one or zero, so 2³², or roughly a little over 4 billion addresses in total. A few of these are saved for private networks. (If you’re thinking 4 billion doesn’t sound like all that many addresses for the whole internet, you’re right! More on that later)
Normally, we’ll have a whole bunch of addresses reserved in a contiguous fashion (together, without breaks). For example, all the addresses starting with 155.189.134.xxx. We get a range that looks like that on the left.
The internet address space used to be split into blocks of different class sizes.
Class A was anything with 8 bits prefix, for example 213.xxx.xxx.xxx, or 14.xxx.xxx.xxx. So there are 256 possible A classes, each containing 16 million addresses.
Class B was anything with 16 bits prefix, so the first 2 full sections fully specified. For example, 18.174.xxx.xxx. Each of these would exist within a larger A class. There are about 65 thousand possible B classes, and each one has 65 thousand addresses in the class.
And lastly Class C, which you can guess, has a prefix of 24 bits, so the first 3 sections fully qualified, for example 203.15.240.xxx. Each exists within a Class B, there are about 16 million of them, and each contains 256 addresses.
But this caused a problem — if address chunks can only be handed out in sizes of 256, 65536 or 16777216, there’s an awful lot of waste. If a company only needed 2 addresses, it would have to ask for a block of 256, wasting a lot of potential addresses. Even worse if they one day moved just beyond 256 addresses, they suddenly had to reserve more than 65 thousand wasted addresses!
In order to solve this problem, the internet moved away from these fixed class sizes, hence “Classless” Inter-Domain Routing. Instead of fixing the size of the class, we can now divide the network into chunks of whatever size we want. We specify a range in the format 123.123.123.123/x. This x defines the size of the chunk of addresses. It essentially says how many bits are fixed at the start of the address. For example, 10.0.0.0/8, translates to the first 8 bits being fixed, having a value of 10 (ie. 00001010, with 24 other bits after it). An address in this range would look something like 10.101.50.34
A smaller range has a more specific prefix. Something like 17.243.92.0/28, has the first 28 bits fixed, with only the last 4 allowed to change in this chunk, so only space for 16 addresses in this chunk.
This meant that we can split the internet address space into more efficient chunks, and there’d be fewer wasted addresses.
What’s IPv6?
So only 4 billion addresses, on a planet with almost 8 billion people? I’ve got 4 iPads in my house! How’s that going to work? Actually, we’ve already run out of addresses at the end of 2019.
But you don’t always need a new IP address in the public space every time you buy a new iPad. A lot of this works by having “private” addresses in your home network, all converted to a single public address, through a process called Network Address Translation (NAT). This means I can have millions of iPads and not exhaust the internet. Which is great, cause that was keeping me up at night.
Unfortunately, this won’t be enough to stem the number of public addresses needed. Thankfully we’ve got the Internet Engineering Task Force (yep, real name, sounds like they fight cybercriminals like a SWAT team with wifi dongles). The IETF developed IPv6 in anticipation of this address exhaustion problem, and also a few other improvements (like security stuff).
They also look different, instead of converting them to decimal, we use hexadecimal, and they look like this: 2001:0db8:0000:0000:0000:8a2e:0370:7334
While IPv4 could only hold 4.2 billion addresses, IPv6 can have 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses. Should be good for a while, will probably cover our whole … solar system!
Unfortunately, the uptake on this great idea has been very very slow. Google’s cloud platform is highly technically advanced, but it doesn’t offer IPv6 support for user private networks. But they do a lot of magic wizard stuff (more later). Basically, it’s an awful lot of effort, and currently there isn’t much reward for doing it, when we have workarounds to get the job done.
DNS
Those addresses are all lovely for computers, but not very memorable. So we give names to websites and computers instead, like bbc.co.uk, wikipedia.org, netflix.com. So how do you turn an easy to remember name into the actual address? This is the Domain Name System, DNS.
Basically, it’s a lot of layered delegation. Say you need to send a request to login.microsoftonline.com, how do you go about asking for that address?
When you join a network and are assigned an address, you also get a pointer to your network’s DNS server.
I’ve got a pointer to Router at 192.168.1.1, and the same address is being used for DNS.
This means I could have some names for devices on my local network. For example, I could store a name in that DNS server for “mark-laptop”. Anyone else using the same DNS server could send a message to “mark-laptop”, which would convert that name back to an actual address, 192.168.1.25
Great, but how does this work on a larger scale?
Humor me for a minute. Due to your newfound network knowledge, you’re now making tons of money in IT. You buy yourself a new car. Car needs tax. You want to tax it. Your dad, or someone who knows about these things, tells you to head over to vehicletax.service.gov.uk to sort it out, so you type that in your browser. Then what happens?
Your browser needs to know the actual address for that server. It’s going to send a request to an address in the form of ones and zeros, so it needs to find the right address first. Before requesting anything from the vehicle tax website, we first go through the motions to find out what that address is.
You first go to your local DNS server. It doesn’t have a service on your network for anything ending in .uk, so it sends the DNS request to the set of root DNS servers. These root servers hold the records for other DNS servers, for the “Top Level Domains”, or TLDs. A top level domain is the last section of an address, like .com, .org, .net, .io, .uk, etc.
You ask for vehicletax.service.gov.uk, so the first thing you need to find is, who is responsible for the “.uk” TLD. Once you have an address for one of those servers, you ask it for “.gov.uk”. Since this server is authoritive for anything ending in “.uk”, it knows where to find “.gov.uk”.
You now ask the DNS servers at “.gov.uk” for “service.gov.uk”. You get an answer back for “service.gov.uk”, and then ask that DNS server finally for “vehicletax.service.gov.uk”. It finally responds with the IP address of the service you actually want. Your browser is now able to send requests to 107.162.171.169, and make those wheels legal!
Akami claimed in 2018 it was serving 2.2 trillion DNS requests per day. So this system relies heavily on caches.
If you want to make your own website, you’d need to buy a domain from a domain registrar, and tell it where to find your servers. There are plenty of top level domains to choose from, but the registrars who control these are tightly regulated.
I learned a lot of this from the book Computer Networking: A top down approach, and studying for the GCP Networking certification. Can’t recommend it enough if you’re slightly interested in networks!
More to come
This took a while to write (I’m not well known for my technical drawings), but it was far from all I found interesting. I’ll follow this up with another with stuff about how email works, how you get an IP address, software defined networks, and content delivery networks.
Follow me and you’ll get notified or it’ll pop up in your feed or something.
Other articles you might like:
