DEV Community: Araiz Naqvi

IPv4: The Foundation of Networking

Araiz Naqvi — Mon, 16 Feb 2026 06:30:00 +0000

When diving into networking, the term IPv4 comes up pretty quickly, and for good reason. It’s one of the key building blocks of the internet today, despite being on the brink of being replaced by its successor, IPv6. Let's break it down.

What is IPv4?

IPv4 stands for Internet Protocol version 4, which is used for identifying devices on a network. Think of it as a street address for your device, allowing data to be sent to the correct location on the vast internet highway.

Unlike a MAC address, which is burned into the device’s hardware by the manufacturer, an IPv4 address is dynamically assigned by a DHCP server (Dynamic Host Configuration Protocol) or can be manually set by the network admin.

An IPv4 address is a 32-bit address, meaning it’s made up of four 8-bit octets, usually represented as four decimal numbers separated by periods (e.g., 192.168.0.1). This format gives around 4.3 billion possible addresses, which, as you might have heard, isn’t enough anymore. Enter IPv6, a new protocol with a much larger address space.

While IPv4 is slowly being phased out in favor of IPv6, it remains the backbone of global internet traffic.

Public vs. Private IPs

In the world of IPv4, there are two major types of IP addresses: public and private.

Private IP addresses are used within a local network (LAN) and are not routable over the internet. They are reserved for internal network use and help maintain security by ensuring devices within your network cannot be directly accessed from outside. Common private IP ranges include 192.168.x.x, 10.x.x.x, and 172.16.x.x to 172.31.x.x.
Public IP addresses, on the other hand, are used to identify devices that are directly accessible from the internet. When a device on a private network needs to access the internet, NAT (Network Address Translation) comes into play. NAT translates the private IP address into a public IP address, allowing the device to communicate with external services.

For example, when you type ping google.com in the terminal, your device’s private IP address is translated to a public IP via your router’s NAT function, and the request reaches the outside world.

The Basics of IPv4 Routing

IPv4 is a connectionless protocol, meaning each packet of data is sent independently and may take different paths to its destination. It’s also important to note that IPv4 only provides best-effort delivery; it doesn’t guarantee data delivery. The job of ensuring reliability falls to higher-layer protocols like TCP (Transmission Control Protocol).

So how do packets get from your device to the right destination? That’s where routing comes in. Routers are responsible for directing data packets between devices on different networks. They use routing protocols to decide the best path based on several factors, such as hop count, network load, and bandwidth.

An important aspect of routing is that it relies on a hierarchical structure for addressing. IPv4 addresses are divided into two main parts:

Network Portion: This part identifies the specific network the device belongs to. It helps routers know which path to take to reach the destination network.
Host Portion: This part identifies the specific device within the network. Once the packet reaches the correct network, it will be forwarded to the correct device based on this portion of the address.

How Does IPv4 Work?

Let’s look at a real-world example. Imagine you’re trying to contact a device within a local network with the IP address 10.1.1.2.

The router will first check the network portion of the destination address (i.e., the first three octets: 10.1.1).
It will then forward the packet to the appropriate network.
Once the packet reaches the network, routers will use the host portion (i.e., the last octet: .2) to identify the specific device and deliver the data.

If you're communicating over the internet, the process is similar but involves more hops, as routers examine the network portion to determine the best path to the destination network and then the host portion to deliver the packet to the right device.

IPv4 Address Format

An IPv4 address is written as four decimal numbers separated by periods, like 10.1.1.1. Each number represents one byte (or 8 bits) and can range from 0 to 255. So, a 32-bit IPv4 address consists of four 8-bit segments:

10: 8 bits
1: 8 bits
1: 8 bits
1: 8 bits

This allows for over 4 billion unique addresses, but as you can imagine, that’s no longer enough. The exponential growth of devices and internet usage has led to IPv4 address exhaustion, which is why IPv6 was introduced to handle the need for a virtually unlimited number of addresses.

Summary

IPv4 might be on the way out, but it's still a core component of how the internet operates today. From dynamically assigning addresses via DHCP to translating private IPs into public ones for internet access, IPv4 plays a crucial role in networking. It’s the backbone of routing, address allocation, and data delivery across the globe.

Application Layer: Where Software Meets the Network

Araiz Naqvi — Sat, 03 Jan 2026 15:30:00 +0000

The Application Layer is the layer that bridges software and the network. It doesn’t change the software itself but provides standards and protocols that allow the software to communicate over the internet. Think of it as a translator: your software speaks its language, the Application Layer translates it into network-friendly language, and voilà — your data travels smoothly.

The most common protocol here is the famous HTTP, or its modern cousin HTTPS. For now, we’ll focus on HTTP — HTTPS involves encryption, which we’ll dive into later.

How It Works: Bob and Larry’s Web Adventure

Imagine the following scenario:

Bob wants to visit the website called home. He makes a request to Larry’s server, which understands it should send back the default webpage. Bob receives home.htm, and it magically appears in his browser.

Seems instant, right? It looks simple, but there’s quite a bit happening behind the scenes — all thanks to HTTP, or Hyper Text Transfer Protocol, created by Tim Berners-Lee in the early 1990s.

HTTP Protocol Mechanism: Step by Step

Here’s what really happens when Bob hits Enter:

Step 1: Bob sends a request to Larry’s server with an HTTP header. The header contains the file name Bob is requesting. If he doesn’t specify, the server just sends the default webpage.

Step 2: Larry’s server responds with an HTTP header and a status code — for example, 200 OK, meaning “All good!” The server sends the first part of the requested file, home.htm.

Step 3: The server sends the rest of the file(s) in parts without headers to reduce redundancy.

HTTP Status Codes: The Server’s Feedback

HTTP status codes are the server’s way of talking back to you.

They’re divided into five categories:

1xx - Informational

100 - Continue: The client should continue with the request
101 - Switching Protocols: The server is switching protocols

(Think: “Hold on, I’m processing this…”)

2xx - Success

200 - OK: Request successful
201 - Created: A new resource was successfully created
204 - No Content: Request succeeded but nothing to return

(Golden responses — everything is perfect!)

3xx - Redirection

301 - Moved Permanently: Resource moved to a new URL
302 - Found: Temporary redirect
304 - Not Modified: Use cached version

(Server saying: “You need to go somewhere else… temporarily or permanently”)

4xx - Client Errors

400 - Bad Request: Syntax or data issue
401 - Unauthorized: Login required
403 - Forbidden: Access denied
404 - Not Found: Resource missing
405 - Method Not Allowed: Wrong method used
408 - Request Timeout: Server waited too long

(Basically: “Your request is broken, fix it!”)

5xx - Server Errors

500 - Internal Server Error: Something went wrong on the server
502 - Bad Gateway: Invalid response from upstream
503 - Service Unavailable: Server temporarily down
504 - Gateway Timeout: Upstream server didn’t respond

(The server’s way of saying: “It’s not you, it’s me…”)

Overview of the TCP/IP Networking Model

Araiz Naqvi — Sun, 28 Dec 2025 15:30:00 +0000

The TCP/IP Model is the backbone of modern networking. It references and defines a wide range of protocols that allow devices to communicate across vast networks. These protocols are formalized using RFCs (Request for Comments) — basically a fancy way of saying, “Hey, we’ve got a standard, let’s agree on it.”

But here’s the interesting bit: The TCP/IP model doesn’t reinvent the wheel. It doesn’t try to give new names or definitions to protocols that other organizations (like the IEEE) have already created. For example, when it talks about Ethernet, it simply says, “Refer to IEEE Ethernet.”

So it’s like an organized librarian who just says, “I don’t need to write a new book on this, just read the existing one.” Very efficient.

The Goal of TCP/IP

The whole point of TCP/IP was to make networking as easy as plug-and-play. The goal was simple: Unbox a device, plug it into the network, and bam, you’re online. No headaches, no long setup processes, just connectivity.

Thanks to TCP/IP, manufacturers of NICs (Network Interface Cards), Ethernet cables, and devices all follow the same set of standards. This means you don’t need to worry about whether your laptop can talk to your router or if your phone will work with your home Wi-Fi. It just does — and it’s all because of the standards and protocols defined in the TCP/IP model.

The Layers of TCP/IP

To help make sense of all this, engineers divided the TCP/IP model into layers. Each layer has a specific job to do, and each one focuses on a different aspect of networking. These layers help organize how data moves from one place to another.

The layers of the TCP/IP model look like this:

(In this module, we’ll talk about the basics of each layer and dive deeper into them along the way.)

The Physical Layer

The Physical Layer is where the magic starts. This is the layer responsible for transmitting data in its most basic form: bits. So, it’s literally all about “pushing data through the wires.” It's like the delivery truck that brings the packages, but doesn't care what's inside. It just gets them from point A to point B.

The Data Link Layer

Next up, we have the Data Link Layer. This layer is in charge of actually sending those bits to the right device. It does so by using a unique identifier known as a MAC Address (Media Access Control). Think of it as the “home address” of every device on the network. Just like a letter needs a postal address to get to the right home, data needs a MAC address to know where it’s going.

The Network Layer

The Network Layer is like a GPS for your data. It helps your data traverse networks, jumping from one router to another until it reaches its destination. This is where the IP (Internet Protocol) lives, and it’s in charge of routing your data between networks, so it can find its way through the maze of routers and switches.

The Transport and Application Layers

Finally, we get to the Transport Layer and Application Layer. These are the layers that deal with the data you actually care about.

The Transport Layer ensures the data is delivered correctly — it’s like making sure your package doesn’t get lost or damaged along the way.
The Application Layer is where all the fun happens. It’s the layer where services like HTTP, FTP, and SMTP live. This is the part of the model where the apps and services that you interact with directly operate. It’s where your email, browsing, and streaming come to life.

Conclusion

The TCP/IP model is the invisible force behind everything you do online. By dividing the tasks of networking into layers, engineers made it easier for devices to communicate, and standardized it all so that it just works — across vendors, countries, and platforms.

It’s efficient, it’s organized, and most importantly, it just works. So the next time you plug in your device, remember: TCP/IP has got your back.

History Leading to the TCP/IP Model

Araiz Naqvi — Sat, 27 Dec 2025 15:30:00 +0000

Today, when we talk about networking, we all pretty much use the TCP/IP model. It’s the standard. The gold standard. But it wasn’t always this simple.

Not too long ago, networking was like the Wild West — every vendor did their own thing, and if you had devices from different manufacturers, you needed a lot of patience (and a lot of technical know-how) to make them talk to each other.

Back in the 1970s and 1980s, IBM held a dominant market share and created its own proprietary network model called SNA (Systems Network Architecture). While IBM was busy claiming the throne, other vendors were off doing their own thing, building incompatible models. The result? A network engineer’s worst nightmare: a patchwork of models that didn’t always play well together.

The Need for a Universal Model

So, what did network engineers do when faced with these different models?
Well, they had to work their magic. They spent hours trying to make these models exchange information—essentially translating languages between incompatible systems. It was like having two people speak different languages, trying to have a conversation with a dictionary in hand.

Let’s take a look at this visual from the early days:

Enter the ISO and OSI Model

To solve this mess, the ISO (International Organization for Standardization) stepped in. They launched a formal effort, bringing together technologically advanced countries to create a standardized networking model. This led to the creation of the OSI (Open Systems Interconnection) model, a seven-layer framework designed to make devices from different vendors talk to each other.

The OSI model, with its structure and defined layers, gave engineers a formal way of understanding how networks should function. It was an ideal concept, but it faced a bit of a challenge — it was complex and slow to catch on.

The Rise of TCP/IP

Meanwhile, across the pond, the US Department of Defense (DoD) had a more practical (and less formal) approach to creating a networking standard. They needed something that could scale across different systems and be reliable in critical situations. Enter TCP/IP.

This model wasn’t born out of a bureaucratic committee but rather from university volunteers who saw the need for a simpler, more adaptable networking system. Over time, TCP/IP became the dominant model, outpacing the OSI model and taking the world by storm.

The Evolution of Networking Models

For a while, both the OSI and TCP/IP models coexisted in organizations. But, like all good things, OSI eventually took a backseat. The simplicity and practicality of TCP/IP won out, and it remains the foundational networking model we use today.

Now that you’ve got a taste of how the TCP/IP model came to be, it’s easy to see how far networking has evolved. From the SNA model to the rise of OSI, and finally the triumphant TCP/IP, it’s been a journey of collaboration, frustration, and ultimately standardization.

Perspectives on Networking

Araiz Naqvi — Fri, 26 Dec 2025 14:57:50 +0000

When you’re new to networking, your perspective is usually very simple — you use the network. You connect your laptop, open a browser, and expect the internet to behave itself.

A network engineer, on the other hand, looks at the same setup and sees cables, devices, protocols, and potential failure points just waiting for the wrong moment to strike.

Neither perspective is wrong. They’re just different viewpoints of the same system.

Let’s start with the most common one: how everyday users experience networking.

Typical Network Usage

In a basic home setup, a PC connects to a cable modem using an Ethernet cable. That cable modem then connects to a cable TV outlet, also known as a CATV wall outlet, to access the internet.

If that sentence sounded like technical noise, don’t worry — that’s normal. Let’s slow it down.

Think of the internet as a massive highway. Your PC is a car that wants to get on that highway. Unfortunately, your PC can’t just merge directly into internet traffic like a reckless driver.

It needs a gatekeeper.

That gatekeeper is the cable modem.

The cable modem connects your home network to your ISP, or Internet Service Provider. The ISP owns the highway and decides who gets access. Data from your ISP travels through the cable TV line, reaches your modem, and the modem translates it into something your PC can actually understand. Without this translation step, your device would just be staring at raw signals wondering what it did wrong.

Now let’s look at a slightly different setup.

Instead of a PC connected by Ethernet, imagine a tablet using Wi-Fi, also called a Wireless Local Area Network (WLAN). No cables, no plugging things in — just vibes and radio waves.

In many setups like this, the internet connection comes through DSL, which stands for Digital Subscriber Line.

DSL uses your telephone line to deliver internet access. Yes, the same line that was once used only for phone calls now carries internet data as well. To make that possible, a DSL modem connects to the phone line and separates voice signals from data signals, converting the internet traffic into a form your wireless devices can use.

So while it looks like magic from the outside, there’s still a lot of networking discipline happening behind the scenes to keep things smooth.

Enterprise Networks

When networking moves beyond homes and into organizations, things scale up quickly.

A network built and maintained by a corporation to allow its employees, systems, and services to communicate is called an enterprise network.

These networks are designed for reliability, performance, and security. Downtime isn’t just annoying here — it’s expensive. Enterprise networks support hundreds or thousands of devices, multiple locations, and strict access controls. This is where networking stops being “plug and play” and starts becoming a serious engineering discipline.

SOHO Networks

Somewhere between a home network and a full enterprise setup lives the SOHO network, short for Small Office / Home Office network.

These are typically home networks used for business purposes — freelancers, small startups, or remote workers running professional operations from home. They’re smaller than enterprise networks but often more complex than a typical household setup.

SOHO networks still need to be reliable and secure, but without the massive infrastructure of a corporate environment. Think of them as networking’s middle child — doing important work, just on a smaller scale.

Why Do Networks Even Work Correctly?

Araiz Naqvi — Thu, 18 Dec 2025 14:29:27 +0000

Have you ever stopped and wondered why the internet usually works?
You tap a link, send a message, or start a video — and most of the time, it just… works.

That’s not luck.
And it’s definitely not vibes.

Networks work because devices and software agree to follow a shared set of rules. Every router, switch, server, and laptop behaves itself. No freelancing allowed.

If they didn’t follow rules, networking wouldn’t be “slow” or “a bit buggy.” It would be complete chaos. Your laptop would be screaming into the void while the router pretends it doesn’t exist.

These rules come in the form of standards and protocols, and they’re the reason your devices don’t act like strangers refusing to make eye contact.

What Are Standards?

Standards are universal guidelines that make sure devices built by different companies can still work together peacefully.

They exist so networking doesn’t turn into a reality show.

Imagine if every phone manufacturer decided to use a completely different charging port.
Oh wait — that already happened, and everyone suffered.

Standards prevent that kind of pain in networking.

They define things like how Ethernet cables send data, how Wi-Fi communicates through the air, and how devices are identified on a network. Thanks to standards like IEEE 802.3, IEEE 802.11, and IP addressing, your laptop can connect to a router it’s never met before and still trust it enough to exchange data.

Without standards, networking would just be very expensive hardware sitting around, aggressively ignoring each other.

What Are Protocols?

If standards are the rules of the road, protocols are the driving instructions.

Protocols define how data is formatted, sent, received, and what happens when something goes wrong — because something always goes wrong.

Think of standards as agreeing to speak English.
Protocols decide how the conversation happens.

Who talks first?
How does the message end?
What happens if someone didn’t hear you and says, “Sorry, say that again?”

Protocols like TCP, IP, HTTP, DNS, SMTP, and HTTPS handle all this quietly in the background. Every time you open a website or send an email, they’re working overtime so you don’t have to think about it.

When protocols do their job well, you don’t notice them at all — which is honestly the highest compliment in networking.

How Standards and Protocols Work Together

Let’s say the network is a big party.

Standards are the house rules. Everyone speaks the same language, uses the same doors, and doesn’t randomly shout over others.

Protocols are the step-by-step social instructions. You walk in, say hello, shake hands, and start a conversation instead of just yelling your life story at strangers.

Standards define what’s allowed.
Protocols define how things actually happen.

Together, they make sure devices don’t just connect — they communicate properly, without awkward misunderstandings.

Networking Models

Now here’s the problem: there are a lot of standards and protocols. Enough to overwhelm even motivated learners.

To keep everyone sane, networking models were created.

A networking model breaks networking into layers, with each layer handling a specific responsibility. This way, engineers don’t have to think about everything at once and lose their minds.

It’s like building a house. Architects, electricians, and plumbers all do different jobs, but they follow the same blueprint. In networking, vendors and engineers follow networking models to design systems that actually work in the real world.

The most commonly used model today is the TCP/IP model.
It’s so widely used that your phone, laptop, router, and probably your smart fridge are all quietly running it right now.