Let's Revise Computer Networks in non-interview approach

If you are someone who hasn’t heard about this topic or is just starting to learn about it, then I recommend checking out these videos on youtube

1. https://www.youtube.com/watch?v=IPvYjXCsTg8&t=9218s

This article just summarises the above yt videos in a friendly story telling format without diving too much in technical details. But if you’re interviews are coming up recently then I recommend going through this

So let’s start with the most basic and fundamental thing: IP addresses.
IP addresses are like our unique identity on the internet. If we want to access the internet, we need an IP address—no exceptions (pretty much like how a house needs a physical address to receive a post). Think of the internet as a giant network where computers talk to each other. That’s why it’s called a computer network.

Now, just like sending a letter requires knowing the recipient’s physical address, interacting with another computer requires knowing its IP address—its public IP address, to be exact. So, what actually happens when we type google.com into our browser? Behind the scenes, our device contacts a special service called DNS (Domain Name System), which acts like the internet’s phonebook. It looks up the domain name and resolves it to Google’s public IP address—the actual numerical address of their server. Once our browser has that IP, it can talk directly to Google’s server and say, “Hey, can you show me the homepage?” Similarly, when we type something like google.com/maps, we’re asking the same server to serve us the Maps page. So clearly, IP addresses are the foundation of how the internet works.

But how do we get our own IP address? And what’s the difference between a public IP and a private IP? Let’s break that down next.

Now essentially there are two types of IP addresses IPv4 and IPv6 (we ran out of IPv4 address so we had to create IPv6 address in case you wondered why there are two), if you inspect for google.com, you’ll see something like this

That right there is an IPv6 address. Now understanding how IP addresses are distributed across the globe and what IP range is assigned to which is pretty complex, so let’s focus on practical part → Public and Private IP address . Now because we were running out of IPv4 addresses, engineers came up with the idea of private IP addresses. If your laptop is connected to a Wi-Fi router, it most likely has a private IP address. Meanwhile, your Wi-Fi router has a public IP address—the one visible to the internet. The router assigns private IP addresses to all connected devices using something called the DHCP protocol (Dynamic Host Configuration Protocol). It’s like the router saying, “Hey phone, you’re 192.168.1.2 now. Laptop, you’re 192.168.1.3.” Now here’s the interesting part: when you open a website on your laptop, your device doesn’t connect to the internet directly using its own IP. Instead, your request is sent to the router, and the router forwards it to the internet using its public IP address.

This process is handled by something called NAT (Network Address Translation). NAT keeps track of all the devices in your network and makes sure that the responses from the internet go back to the correct device. In simple terms your router remembers the device by it’s private address, it keeps track which request came from which and serves it the respective content.

Now that we understand how we connect to the internet using public and private IPs, a new question arises: How do we get these IP addresses? And how does DNS figure out which IP belongs to which website?

Let’s say your laptop has a public IP address. (In reality, this is more like a VPS server—for example, an EC2 instance hosted on AWS—that has its own public IP.) Now imagine you’re running a React application on port 3000. Anyone on the internet can access your site by visiting something like: http://192.48.1.4:3000 . Simple, right? But not very user-friendly. It's like trying to remember someone’s phone number instead of their name. That’s where DNS (Domain Name System) comes in. It acts like the internet’s phonebook, keeping track of which domain name points to which IP address. So instead of asking users to remember 192.48.1.4, you can register a domain name like mycoolproject.com, and DNS will take care of connecting the two.

Let’s go back to the example we discussed earlier—when someone types example.com, how exactly does DNS resolve it to Google’s IP address? (This part might get a little technical, so feel free to skip the details and just remember that DNS converts domain names like example.com into IP addresses.)

So first, let’s break down the domain: https://example.com consists of three parts:

• https tells the browser which protocol to use (in this case, secure HTTP, it’s actually used for the port http uses port 80 and https uses port 443).

• example is the domain name—basically, the identity of the website.

• .com is the top-level domain (TLD), like .net, .org, .in, etc.

Now, when our request reaches the DNS resolver, it doesn’t magically know the IP address. Instead, it follows a chain of steps to figure it out:

1. First, the resolver forwards the request to a Root DNS Server. This server doesn’t know the IP for example.com, but it knows who handles .com domains, so it points us to the TLD name server for .com.

2. The TLD name server then responds with the address of the authoritative name server for example.com.

3. Finally, the authoritative name server responds with the actual IP address of example.com.

This three-step process happens in a matter of milliseconds (sometimes even microseconds), and boom—your browser now knows where to send the request!

Now, a few questions might naturally pop into your head, If the DNS server is responsible for converting every single domain name into an IP address...And this happens every time someone visits a website...
How does it scale? Isn’t that too much load on a single system? How is it distributed across the globe?

Honestly, it’s not that complex—but it’s definitely not as simple as it seems either. DNS is designed to be globally distributed and heavily cached, which helps it scale almost infinitely and stay fast for users everywhere. Watch this if you’re curious → https://youtu.be/g_gKI2HCElk?si=ILX_d6u5sGfzBBdz

So yeah, once you get the hang of it, DNS starts to feel pretty straightforward. You buy a domain—let’s say yourproject.com—and then you just point it to your server’s public IP address. That way, when someone types your domain in the browser, DNS takes care of translating it to the correct IP so users reach your site. Simple enough, right?

Behind the scenes, you do this by adding DNS records. The most common one is the A record, which maps your domain to an IPv4 address like 192.48.1.4. If you’re using an IPv6 address, you’d use an AAAA record instead. There are also other types of records you might come across. For example, a CNAME record lets you point one domain to another domain instead of directly to an IP address. It's useful for things like pointing www.yourproject.com to yourproject.com so they both show the same site.

Now, we've been saying all along that one machine can talk to another using IP addresses. But how does that actually work?

Well, that communication happens using protocols—basically agreed-upon rules for exchanging data over a network. One of the most widely used protocols is TCP (Transmission Control Protocol). There are others too, like UDP, SMTP, and FTP, but let’s stick with TCP for now.

To really understand TCP, it helps to look at it from a client-server perspective. Imagine your browser (the client) wants to talk to a server (like Google). Before they start exchanging data, they need to establish a stable connection. That’s where TCP’s famous three-way handshake comes in (all the communication happens in form of data packets small fragments which tranmits the data over internet)

The above picture shows how a connection is established between two machines. If that feels too abstract, just think of it like this: you call someone, they pick up, and only then do you start talking — that’s pretty much what happens during the TCP three-way handshake. Once that handshake is complete, the real conversation begins.

For example, your browser might send an HTTP GET request asking for the homepage, and the server can respond with HTML, CSS, or even JavaScript files. Because TCP ensures all packets arrive in the correct order, this exchange is stable and reliable — which is exactly what you want when loading a webpage.

Now, while TCP is solid, it’s not the fastest because of all this back-and-forth handshaking and acknowledgments. But that’s okay — for some use cases, we can afford to be a little less careful. Think video streaming or live audio — this is where UDP (User Datagram Protocol) comes in. It skips the handshake, sends data straight away, and doesn’t cry over a few lost packets. That’s why it’s blazing fast. And if a few seconds of music or a video frame gets skipped? Most people won’t even notice.

If you’ve made it this far, you’re clearly curious — and I appreciate that. Ping me on x.com at @yetanothercode (you’ll see luffy profile photo) or drop an email at srivastavaaryanalc76@gmail.com with the code blo0Dy, and I’ll send you ₹50.