Chapter 2.2: Networking Basics

The Foundation: Why Networking Matters

In Chapter 2.1, we mastered the Operating System (Linux). That is the "ground" our servers run on. Now, we learn about the "roads" that connect them. **Networking** is the fundamental study of how computers talk to each other.

As a DevOps engineer, you live in the network. You don't just "use" the network; you *build* it, *manage* it, and *debug* it. When a developer says "My app can't reach the database," they come to *you*. You are the one who has to figure out *why*.

Is it a DNS problem? Is a firewall blocking the port? Is a router misconfigured? This chapter will teach you how to answer those questions. We will cover the entire **TCP/IP stack**, the "language" of the internet.

Part 1: Network Models (OSI vs. TCP/IP)

To understand networking, we use "models." A model is a way of separating a complex process (like sending a message) into smaller, manageable layers. You will hear about two models: OSI (theoretical) and TCP/IP (practical).

The OSI Model (The 7-Layer Theoretical Model)

The OSI (Open Systems Interconnection) model is a 7-layer *conceptual* model. It was designed by academics to be the "perfect" standard. It's great for *understanding* networking theory, but it's not what the internet *actually* uses. You need to know the 7 layers for interviews.

[Image of the 7-layer OSI Model (Physical, Data Link, Network, Transport, Session, Presentation, Application)]

Layer 7 (Application): The "human" layer. The app you interact with (e.g., your Chrome browser, Discord). (Protocol: HTTP, FTP, SMTP).
Layer 6 (Presentation): The "translator." Formats data, handles encryption/decryption (SSL/TLS).
Layer 5 (Session): The "conversation manager." Establishes, manages, and terminates the connection between two apps.
Layer 4 (Transport): The "reliability" layer. How data is sent (reliably or not). (Protocols: **TCP**, **UDP**).
Layer 3 (Network): The "addressing & routing" layer. Finds the best path from A to B. (Protocol: **IP**).
Layer 2 (Data Link): The "local delivery" layer. Handles communication between two devices on the *same* local network. (Protocol: Ethernet, MAC Addresses).
Layer 1 (Physical): The actual "hardware." The wires, fiber optics, Wi-Fi radio waves.

The TCP/IP Model (The 4-Layer Practical Model)

This is the model the internet *actually* runs on. It's simpler (4 layers) and more practical. This is the one you *must* master.

[Image of the 4-layer TCP/IP Model (Link, Internet, Transport, Application)]

Layer 4 (Application): Same as OSI. This is where protocols like **HTTP**, **SSH**, and **DNS** live.
Layer 3 (Transport): Same as OSI. This is where **TCP** and **UDP** live. This layer is all about **Ports**.
Layer 2 (Internet): Same as OSI. This is where the **IP** protocol lives. This layer is all about **IP Addresses**.
Layer 1 (Link):** Same as OSI. This is the hardware, like Ethernet and Wi-Fi.

For the rest of this chapter, we will work our way *up* this practical TCP/IP stack, from Layer 2 to Layer 4.

Part 2: The Internet Layer (IP Addresses)

An **IP (Internet Protocol) Address** is the unique "house address" for a device on a network. Just like a postman needs your address to deliver a letter, one server needs another server's IP address to send it data. Every server, computer, and phone on the internet has at least one.

IPv4 vs. IPv6

IPv4 (The Old Standard)

What it is: The original IP format (e.g., 172.217.14.228).

How it works: It's a 32-bit number (four 8-bit numbers, called "octets").

The Problem: A 32-bit number only allows for 2^32 (about **4.2 billion**) unique addresses. With phones, laptops, smart TVs, and servers, **we have officially run out of IPv4 addresses.**

IPv6 (The New Standard)

What it is: The new, much longer format (e.g., 2001:0db8:85a3:0000:0000:8a2e:0370:7334).

How it works: It's a 128-bit number.

The Benefit: 128 bits allows for 2^128, or **340 undecillion** (3.4 x 10^38) addresses. This is a ridiculously large number. We will never run out of IPv6 addresses.

DevOps Note:** All modern cloud providers (AWS, GCP) are "dual-stack" (they support both), but you should build new infrastructure with IPv6 in mind.

Public vs. Private IP & NAT

We ran out of IPv4 addresses, so how does the internet still work? With a clever trick called **NAT (Network Address Translation)**. This creates two "worlds" of IP addresses: Public and Private.

Public IP: Your "main" address on the global internet. Your ISP (Airtel, Jio) gives you *one* of these for your whole house. This IP is unique in the world.

Private IP: Your *internal* addresses, used *inside* your house/office network. They are not reachable from the internet. They *always* start with one of these reserved blocks:

192.168.x.x (Most common for home Wi-Fi)

10.x.x.x (Common in big companies)

172.16.x.x - 172.31.x.x

Your Wi-Fi Router acts as the NAT. It "owns" the one Public IP. When your laptop (192.168.1.10) wants to go to google.com, it sends the request to the router. The router "translates" the request, sends it to Google using the **Public IP**, gets the response, and then translates it *back* to your laptop. This is how 100 devices in your house can all share one Public IP.

Subnetting & CIDR (CRITICAL)

This is the most important IP concept for cloud (AWS/GCP). A **Subnet** is a "sub-division" of a network.
How do you tell a computer which part of an IP is the "Network" and which part is the "Device"?

Method 1: The Old Way (Subnet Mask)

A subnet mask is a 32-bit number (like an IP) that "masks" the device part. 255 means "This part is the Network." 0 means "This part is for Devices."

IP Address: 192.168.1.50

Subnet Mask: 255.255.255.0

Translation: The first three octets (192.168.1) are the **Network ID**. The last octet (.50) is the **Host/Device ID**. This network (192.168.1.x) can have 254 usable devices (from .1 to .254).

Method 2: The New Way (CIDR Notation)

CIDR (Classless Inter-Domain Routing) is the modern, short way to write this. You just write a / followed by the number of bits that are the "Network".

/24: This means the first 24 bits (8+8+8) are the network.
192.168.1.0/24 is the *exact same thing* as 255.255.255.0. It gives you 254 addresses.

/16: This means the first 16 bits (8+8) are the network.
10.0.0.0/16 is the *exact same thing* as 255.255.0.0. It gives you 65,534 addresses (from 10.0.0.1 to 10.0.255.254).

/32: This means all 32 bits are the network. It refers to *one single IP address*.

When you create a **VPC (Virtual Private Cloud)** in AWS, the *first* thing it asks for is your CIDR block (e.g., 10.0.0.0/16). You then divide this into smaller "subnets" (e.g., 10.0.1.0/24 for your web servers, 10.0.2.0/24 for your databases).

Part 3: The Transport Layer (TCP/UDP) & Ports

If the IP Address is the "house address" of your server building, the **Port** is the "apartment number" for a *specific service* (program) running inside that server.

Your server (104.21.92.100) is running multiple services at once. How does a user's request know if it's for the website or for your SSH login?

Your Nginx web server "listens" on **Port 80** (HTTP) and **Port 443** (HTTPS).

Your SSH service "listens" on **Port 22**.

A "socket" is the combination of an IP and a Port (e.g., 104.21.92.100:443).

TCP (Transmission Control Protocol)

Analogy: A Phone Call.

How it works: It's **connection-oriented**. Before any data is sent, a "call" is established using the **3-Way Handshake**.

**Client -> Server:** SYN (Can we talk?)

**Server -> Client:** SYN-ACK (Yes, I'm here! Can you hear me?)

**Client -> Server:** ACK (Yes, I hear you. Let's talk.)

Pros: **Reliable.** 100% of data is guaranteed to arrive. Packets are numbered, sent in order, and confirmed (ACK'd). If a packet is lost, it's re-sent.

Cons: Slower, more overhead.

Used for: **HTTP/HTTPS** (websites), **SSH**, **FTP** (file transfer), **SMTP** (email). Everything where 100% data integrity is critical.

UDP (User Datagram Protocol)

Analogy: A Postcard.

How it works: It's **connectionless**. You just write the data, put the address on it, and "fire and forget."

Pros: **Fast.** Very low overhead, no handshake.

Cons: **Unreliable.** Packets (datagrams) can be lost, arrive out of order, or be duplicated.

Used for: **DNS**, **VoIP** (Zoom/Skype calls), **online gaming**. Everything where *speed* is more important than 100% accuracy. (It's better to miss one frame of a video call than to have it pause for 5 seconds to re-download a lost packet).

Key Ports You MUST Memorize:

A "firewall" is a tool that *blocks* ports. A common DevOps task is "opening port 80" in the firewall so the web server can receive traffic.

21: FTP (File Transfer Protocol - insecure)

22: **SSH** (Secure Shell) - How you log in to your Linux servers.

25: SMTP (Simple Mail Transfer Protocol) - Used to send email.

53: **DNS** (Domain Name System) - The "phonebook" service.

80: **HTTP** (Hypertext Transfer Protocol) - Unsecured web traffic.

443: **HTTPS** (HTTP Secure) - Secured (encrypted) web traffic.

3306: **MySQL** - Common database.

5432: **PostgreSQL** - Common database.

6379: **Redis** - Common in-memory cache.

Part 4: The Application Layer (The Services)

This is the final layer. These are the "human" protocols that run *on top of* TCP or UDP.

1. DNS (Domain Name System) - The Phonebook

DNS is the "phonebook" of the internet. It's a massive, global, distributed database that translates human-readable names (codewithmsmaxpro.me) into computer-readable IP addresses (104.21.92.100).

How it Works (The Query Flow):

When you type google.com into your browser, this happens in milliseconds:

Your browser asks your **Recursive Resolver** (usually your ISP, e.g., Airtel, or a public one like 8.8.8.8 - Google's DNS).

The Resolver (if it doesn't have it cached) asks one of the 13 **Root Servers** ("Where can I find .com?").

The Root Server replies: "I don't know, but ask the .com **TLD Server**."

The Resolver asks the .com TLD Server ("Where can I find google.com?").

The TLD Server replies: "I don't know, but ask Google's **Authoritative Nameserver** (e.g., ns1.google.com)."

The Resolver asks ns1.google.com ("What is the IP for google.com?").

The Authoritative Server *finally* answers: "The IP is 142.250.196.78."

The Resolver sends this IP back to your browser. Your browser then makes a TCP connection to that IP on port 443.

Common DNS Record Types (CRITICAL for DevOps)

As a DevOps engineer, you will manage your company's "Authoritative Nameserver" (e.g., on AWS Route 53, GoDaddy, or Cloudflare). You will be in charge of these records:

A Record (Address): The most common. Maps a domain (@) or subdomain (www) to an **IPv4 address**.
codewithmsmaxpro.me -> 104.21.92.100

AAAA Record (Quad-A): Maps a domain to an **IPv6 address**.

CNAME (Canonical Name): Maps a domain to *another domain*. This is an "alias."
www.codewithmsmaxpro.me -> codewithmsmaxpro.me
This is very useful. If your IP changes, you only have to update the one 'A' record, and all your CNAMEs update automatically.

MX (Mail Exchange):** Tells the world where to send **email** for your domain.
codewithmsmaxpro.me -> 10 aspmx.l.google.com (This points to Google Workspace/Gmail).

TXT (Text):** Used to store arbitrary text. Its main use is for **verification**. When you sign up for Google Workspace, they will ask you to create a TXT record with a special code (e.g., "google-site-verification=...") to *prove* you own the domain.

2. HTTP (Hypertext Transfer Protocol)

We covered this briefly in the REST section. This is the "language" of the web. It's a request-response protocol. The client (browser) sends an **HTTP Request** and the server (Nginx) sends an **HTTP Response**.

Anatomy of an HTTP Request

GET /api/users/123 HTTP/1.1 Host: api.example.com User-Agent: MyAndroidApp/1.0 Authorization: Bearer my_secret_token Accept: application/json (Body would go here for a POST request)

Anatomy of an HTTP Response

HTTP/1.1 200 OK Content-Type: application/json Content-Length: 150 Date: Mon, 10 Nov 2025 12:00:00 GMT { "id": 123, "name": "MSMAXPRO" }

3. HTTPS (HTTP Secure)

HTTP is plain text. Anyone "sniffing" your Wi-Fi can read your passwords. This is why **HTTPS** was invented. It's *not* a new protocol. It is just **HTTP + SSL/TLS**.

SSL (Secure Sockets Layer), now called TLS (Transport Layer Security), is an encryption "layer" that wraps your HTTP request.
When you connect to https://google.com:

Your browser and Google's server perform an **SSL Handshake**.

They use **Public/Private Key Cryptography** to securely agree on a shared secret **Symmetric Key**.

*After* this secure channel is built, they start sending the normal HTTP requests (GET, POST) *inside* this encrypted tunnel.

As a DevOps engineer, your job is to set this up on your server. You get an **SSL Certificate** from a **Certificate Authority (CA)** (like Let's Encrypt - which is free) and install it in Nginx. This is what enables the "lock" icon in the browser.

Part 5: Practical Networking Tools (Command Line)

These are the commands you will use *every day* to debug problems.

ping

**Question:** "Is this server alive and can I reach it?"
It sends an ICMP "echo request" packet and waits for an "echo reply."

$ ping google.com PING google.com (142.250.196.78): 56 data bytes 64 bytes from 142.250.196.78: icmp_seq=0 ttl=116 time=5.483 ms 64 bytes from 142.250.196.78: icmp_seq=1 ttl=116 time=5.234 ms # 'time=5.483 ms' is your "latency" or "lag". # If this fails, you have a basic connectivity problem.

ss (or netstat)

**Question:** "What ports are listening on my server?"
ss (Socket Statistics) is the modern version of netstat. It's used to see all open connections and listening ports.

# Show all listening (l) TCP (t) and UDP (u) ports, # show numbers (n) and the process (p) using them. $ sudo ss -ltunp Proto Recv-Q Send-Q Local Address:Port Peer Address:Port Process tcp LISTEN 0 127.0.0.1:5432 0.0.0.0:* (postgres) tcp LISTEN 0 0.0.0.0:80 0.0.0.0:* (nginx) tcp LISTEN 0 0.0.0.0:22 0.0.0.0:* (sshd)

This output is your #1 tool. It tells us that our server is running PostgreSQL (port 5432), Nginx (port 80), and SSH (port 22). If Nginx was crashed, you would *not* see port 80 in this list.

dig (Domain Information Groper)

**Question:** "What is the DNS record for this domain?"
This is the main tool for debugging DNS.

$ dig codewithmsmaxpro.me ... ;; QUESTION SECTION: ;codewithmsmaxpro.me. IN A ;; ANSWER SECTION: codewithmsmaxpro.me. 300 IN A 104.21.92.100 codewithmsmaxpro.me. 300 IN A 172.67.199.23 ...

This tells us that codewithmsmaxpro.me has an "A" (Address) record pointing to two IP addresses (this is common for load balancing). The "300" is the **TTL (Time to Live)** in seconds, meaning other resolvers will cache this record for 5 minutes (300s).

traceroute (or mtr)

**Question:** "My server is alive (ping works), but the connection is very slow. Where is the bottleneck?"
traceroute shows you every "hop" (router) your data packet takes between you and the server.

$ traceroute google.com traceroute to google.com (142.250.196.78), 30 hops max 1 192.168.1.1 (my-router) 1.5 ms 2 airtel-del-1.isp.net (isp-router) 5.2 ms 3 ... 4 ... (many hops) ... 5 108.170.253.1 (google-router) 25.4 ms 6 142.250.196.78 (google-server) 25.6 ms

If you see a sudden jump in time (e.g., from 5ms to 200ms) at a specific hop, you know where the network lag is.
Read More about the TCP/IP Model →
← Chapter 2.1: The OS (Linux) Next Chapter: Version Control (Git) →

Chapter 2.2: Networking Basics

The Foundation: Why Networking Matters

Part 1: Network Models (OSI vs. TCP/IP)

The OSI Model (The 7-Layer Theoretical Model)

The TCP/IP Model (The 4-Layer Practical Model)

Part 2: The Internet Layer (IP Addresses)

IPv4 vs. IPv6

IPv4 (The Old Standard)

IPv6 (The New Standard)

Public vs. Private IP & NAT

Subnetting & CIDR (CRITICAL)

Method 1: The Old Way (Subnet Mask)

Method 2: The New Way (CIDR Notation)

Part 3: The Transport Layer (TCP/UDP) & Ports

TCP (Transmission Control Protocol)

UDP (User Datagram Protocol)

Key Ports You MUST Memorize:

Part 4: The Application Layer (The Services)

1. DNS (Domain Name System) - The Phonebook

How it Works (The Query Flow):

Common DNS Record Types (CRITICAL for DevOps)

2. HTTP (Hypertext Transfer Protocol)

Anatomy of an HTTP Request

Anatomy of an HTTP Response

3. HTTPS (HTTP Secure)

Part 5: Practical Networking Tools (Command Line)

`ping`

`ss` (or `netstat`)

`dig` (Domain Information Groper)

`traceroute` (or `mtr`)

Chapter 2.2: Networking Basics

The Foundation: Why Networking Matters

Part 1: Network Models (OSI vs. TCP/IP)

The OSI Model (The 7-Layer Theoretical Model)

The TCP/IP Model (The 4-Layer Practical Model)

Part 2: The Internet Layer (IP Addresses)

IPv4 vs. IPv6

IPv4 (The Old Standard)

IPv6 (The New Standard)

Public vs. Private IP & NAT

Subnetting & CIDR (CRITICAL)

Method 1: The Old Way (Subnet Mask)

Method 2: The New Way (CIDR Notation)

Part 3: The Transport Layer (TCP/UDP) & Ports

TCP (Transmission Control Protocol)

UDP (User Datagram Protocol)

Key Ports You MUST Memorize:

Part 4: The Application Layer (The Services)

1. DNS (Domain Name System) - The Phonebook

How it Works (The Query Flow):

Common DNS Record Types (CRITICAL for DevOps)

2. HTTP (Hypertext Transfer Protocol)

Anatomy of an HTTP Request

Anatomy of an HTTP Response

3. HTTPS (HTTP Secure)

Part 5: Practical Networking Tools (Command Line)

ping

ss (or netstat)

dig (Domain Information Groper)

traceroute (or mtr)

`ping`

`ss` (or `netstat`)

`dig` (Domain Information Groper)

`traceroute` (or `mtr`)