What SSH actually is?

Not just secure telnet. SSH is three protocols stacked on top of each other, all defined in RFC 4251–4254

All of this rides on TCP port 22 (one persistent TCP connection)

The binary packet format (RFC 4253)

Every SSH message after key exchange looks like this

┌──────────────────────────────
│  uint32   packet_length  (4 bytes)            │
│  byte     padding_length (1 byte)             │
│  byte[]   payload        (variable)           │
│  byte[]   random_padding (padding_length)     │
│  byte[]   MAC            (variable, optional) │
└──────────────────────────────

• packet_length = length of everything AFTER the length field itself

• Padding is added to make packet_length + padding_length + 1 a multiple of cipher block size (or 8)

• MAC (Message Authentication Code) covers: sequence number + packet content — not encrypted, computed over plaintext then appended to ciphertext

NOTE: SSH is NOT TLS. It has its own key exchange, its own record format, its own MAC scheme.

THE FULL CONNECTION LIFECYCLE

Phase 0: TCP Handshake

Before SSH does anything, TCP happens:

Client → SYN        → Server
Client ← SYN-ACK   ← Server
Client → ACK        → Server

3 packets. Connection established on port 22.

Observable

tcpdump -i eth0 'tcp port 22' -nn

Phase 1: Version Exchange (RFC 4253)

First thing both sides do — send a plaintext identification string

Server → "SSH-2.0-OpenSSH_9.3\r\n"
Client → "SSH-2.0-OpenSSH_9.3\r\n"

• This is cleartext — fully visible in Wireshark

• Format: SSH-protoversion-softwareversion [comments]

• Client and server both record each other's version — used later in key exchange hash

• If versions are incompatible, connection drops immediately

Observable

# Capture the banner
nc -v 192.168.1.100 22
# or
ssh -vvv user@host 2>&1 | head -20

Phase 2: Algorithm Negotiation — KEXINIT (RFC 4253)

Both sides send a SSH_MSG_KEXINIT packet simultaneously (no waiting). This is the "menu"

byte         SSH_MSG_KEXINIT (20)
byte[16]     cookie (random bytes)
name-list    kex_algorithms
name-list    server_host_key_algorithms
name-list    encryption_algorithms_client_to_server
name-list    encryption_algorithms_server_to_client
name-list    mac_algorithms_client_to_server
name-list    mac_algorithms_server_to_client
name-list    compression_algorithms_client_to_server
name-list    compression_algorithms_server_to_client
...

Negotiation rule: client's preference list wins — first algorithm in the client's list that the server also supports is chosen.

Typical modern negotiation result:

Observable

ssh -vvv user@host 2>&1 | grep -E 'kex|cipher|mac|compress'
# Shows:
# kex: algorithm: curve25519-sha256
# kex: host key algorithm: ssh-ed25519
# kex: server->client cipher: chacha20-poly1305...

Phase 3: Key Exchange — The Cryptographic Heart (RFC 4253)

This is the most important phase. Using Diffie-Hellman or ECDH to establish a shared secret without transmitting it.

With curve25519-sha256 (most modern):

Step 1 — Client generates ephemeral keypair:

client_private_key = random scalar (32 bytes)
client_public_key  = scalar × G  (Curve25519 base point)

Step 2 — Client sends SSH_MSG_KEX_ECDH_INIT:

byte      SSH_MSG_KEX_ECDH_INIT (30)
string    Q_C  ← client's ephemeral public key

Step 3 — Server computes shared secret + signs everything:

Server has:

• Its own ephemeral keypair (server_priv, server_pub)

• Client's public key Q_C

Server computes:

K (shared_secret) = server_priv × Q_C
                  = client_priv × Q_S  (ECDH magic — same result both sides)

Server builds exchange hash H:

H = SHA-256(
  V_C || V_S ||         ← version strings from Phase 1
  I_C || I_S ||         ← KEXINIT payloads from Phase 2
  K_S  ||               ← server's HOST key (public, long-term)
  Q_C  ||               ← client's ephemeral pubkey
  Q_S  ||               ← server's ephemeral pubkey
  K                     ← shared secret
)

Server sends SSH_MSG_KEX_ECDH_REPLY:

string    K_S     ← server host public key
string    Q_S     ← server ephemeral public key
string    sig_H   ← signature of H using K_S (host key)

Step 4 — Client verifies:

1. Compute K = client_priv × Q_S  (same shared secret!)
2. Recompute H
3. Verify sig_H using K_S
4. Check K_S against known_hosts (TOFU or CA)

Critical insight: The shared secret K is never transmitted. Both sides compute it independently. Even if someone recorded all packets, they cannot compute K without either private key. This is Forward Secrecy.

Step 5 — Key Derivation (RFC 4253)

From K and H, six keys are derived using the hash:

IV  client→server  = HASH(K || H || "A" || session_id)
IV  server→client  = HASH(K || H || "B" || session_id)
Key client→server  = HASH(K || H || "C" || session_id)
Key server→client  = HASH(K || H || "D" || session_id)
MAC client→server  = HASH(K || H || "E" || session_id)
MAC server→client  = HASH(K || H || "F" || session_id)

From this point forward: all packets are encrypted.

Step 6 — SSH_MSG_NEWKEYS: Both sides send this to say "switching to new keys now." One packet each.

Phase 4: SSH Authentication Layer (RFC 4252)

Now inside encrypted tunnel. Client must prove identity.

Step 1 — Service request:

SSH_MSG_SERVICE_REQUEST → "ssh-userauth"
SSH_MSG_SERVICE_ACCEPT  ← server confirms

Step 2 — Auth methods (tried in order):

Method A: publickey (most common)

1. Client sends probe:
   SSH_MSG_USERAUTH_REQUEST {
     username, "ssh-connection", "publickey",
     FALSE,  ← just checking if key is acceptable
     "ssh-ed25519", public_key_blob
   }

2. Server responds SSH_MSG_USERAUTH_PK_OK if key is in authorized_keys

3. Client sends actual auth:
   SSH_MSG_USERAUTH_REQUEST {
     ..same..,
     TRUE,   ← now actually signing
     signature of (session_id || request_data) using private key
   }

4. Server verifies signature → SSH_MSG_USERAUTH_SUCCESS

Where is authorized_keys checked?

~/.ssh/authorized_keys  (default)
# or configured via AuthorizedKeysFile in sshd_config
# or AuthorizedKeysCommand for LDAP/Vault lookups

Method B: password

SSH_MSG_USERAUTH_REQUEST {
  username, "ssh-connection", "password",
  FALSE,
  plaintext_password  ← encrypted by transport layer!
}

Method C: keyboard-interactive (used for MFA/PAM)

Multi-round challenge-response. Used by Google Authenticator PAM, Duo, etc.

Observable

ssh -vvv user@host 2>&1 | grep -E 'auth|Authentications'
# debug1: Authentications that can continue: publickey,password
# debug1: Next authentication method: publickey
# debug1: Offering public key: /home/user/.ssh/id_ed25519

Phase 5: SSH Connection Layer — Channel Multiplexing (RFC 4254)

Authentication passed. Now the connection protocol opens logical channels over the single TCP connection.

Opening a channel

Client → SSH_MSG_CHANNEL_OPEN {
  channel_type: "session"
  sender_channel: 0
  initial_window_size: 2097152  (2MB)
  maximum_packet_size: 32768
}

Server → SSH_MSG_CHANNEL_OPEN_CONFIRMATION {
  recipient_channel: 0
  sender_channel: 0
  initial_window_size: ...
  maximum_packet_size: ...
}

Requesting a PTY (pseudo-terminal):

SSH_MSG_CHANNEL_REQUEST {
  channel: 0
  request_type: "pty-req"
  want_reply: TRUE
  TERM: "xterm-256color"
  width_chars, height_chars, width_px, height_px
  terminal_modes: (speed, echo, etc.)
}

Requesting a shell:

SSH_MSG_CHANNEL_REQUEST {
  channel: 0
  request_type: "shell"
  want_reply: TRUE
}

Data flow:

Client → SSH_MSG_CHANNEL_DATA { channel: 0, data: "ls -la\n" }
Server → SSH_MSG_CHANNEL_DATA { channel: 0, data: "total 48\n..." }

Flow control — window adjust:

When receiver's buffer fills:
SSH_MSG_CHANNEL_WINDOW_ADJUST { channel: 0, bytes_to_add: 2097152 }

Key insight: Multiple channels can run simultaneously — shell + port forwards + X11 — all multiplexed over one TCP connection with independent flow control windows

Phase 6: Session Teardown

User types exit → shell sends EOF
SSH_MSG_CHANNEL_EOF    (no more data from this side)
SSH_MSG_CHANNEL_CLOSE  (I'm done with this channel)
SSH_MSG_DISCONNECT {
  reason_code: SSH_DISCONNECT_BY_APPLICATION
  description: "logout"
}
TCP FIN/ACK

OBSERVABILITY DEEP DIVE

Tool 1: ssh -vvv — Built-in debug

ssh -vvv -o 'LogLevel=DEBUG3' user@host 2>&1 | less

Shows every protocol message, algorithm chosen, key used.

Tool 2: Wireshark / tshark — Packet-level

# Capture SSH handshake (cleartext phase visible)
tshark -i eth0 -f 'tcp port 22' -w /tmp/ssh.pcap

# Analyze
tshark -r /tmp/ssh.pcap -Y 'ssh' -T fields \
  -e frame.number -e ssh.message_code -e ssh.kex.algorithms

In Wireshark:

• Filter: ssh

• You'll see: Protocol: SSHv2, message types like Key Exchange Init, Elliptic Curve Diffie-Hellman Key Exchange Init/Reply, New Keys

• After New Keys: everything shows as Encrypted packet

Tool 3: strace — System call level

# Trace the ssh client
strace -e trace=network,read,write -f ssh user@host 2>&1 | head -100

# On server side, trace sshd for a specific connection
strace -p $(pgrep -f "sshd: user") -e trace=read,write

Tool 4: eBPF / bpftrace — Zero overhead production observability

# Trace all connect() calls to port 22
bpftrace -e '
  tracepoint:syscalls:sys_enter_connect /
    ((struct sockaddr_in *)args->uservaddr)->sin_port == 5632
  / {
    printf("SSH connect: pid=%d comm=%s\n", pid, comm);
  }'

# Watch SSH data writes (channel data)
bpftrace -e '
  kprobe:tcp_sendmsg /comm == "ssh"/ {
    printf("ssh write: pid=%d bytes=%d\n", pid, arg2);
  }'

Tool 5: /proc and kernel crypto — See what's happening inside

# See active SSH connections
ss -tnp | grep :22

# Check which crypto is loaded
cat /proc/crypto | grep -A5 'curve25519\|chacha20'

# OpenSSL timing of key exchange (benchmark)
openssl speed curve25519 ed25519

Tool 6: sshd debug mode — Server-side visibility

# Run sshd in debug mode on alternate port (non-disruptive)
/usr/sbin/sshd -d -p 2222

# Full verbose
/usr/sbin/sshd -ddd -p 2222

THE FULL PICTURE

Complete timeline of one SSH connection

t=0ms    TCP SYN
t=1ms    TCP SYN-ACK
t=2ms    TCP ACK ──────────────────── TCP established

t=3ms    Server → SSH banner (cleartext)
t=4ms    Client → SSH banner (cleartext)

t=5ms    Client → SSH_MSG_KEXINIT
t=5ms    Server → SSH_MSG_KEXINIT (simultaneous)

t=6ms    Client → SSH_MSG_KEX_ECDH_INIT  (client ephemeral pubkey)
t=8ms    Server → SSH_MSG_KEX_ECDH_REPLY (host key + sig + server pubkey)

t=8ms    [Both sides derive 6 symmetric keys]

t=9ms    Client → SSH_MSG_NEWKEYS
t=9ms    Server → SSH_MSG_NEWKEYS
         ──────────────────────── EVERYTHING ENCRYPTED FROM HERE

t=10ms   Client → SSH_MSG_SERVICE_REQUEST ("ssh-userauth")
t=11ms   Server → SSH_MSG_SERVICE_ACCEPT

t=12ms   Client → SSH_MSG_USERAUTH_REQUEST (publickey probe)
t=13ms   Server → SSH_MSG_USERAUTH_PK_OK
t=14ms   Client → SSH_MSG_USERAUTH_REQUEST (signed)
t=15ms   Server → SSH_MSG_USERAUTH_SUCCESS

t=16ms   Client → SSH_MSG_CHANNEL_OPEN ("session")
t=17ms   Server → SSH_MSG_CHANNEL_OPEN_CONFIRMATION
t=18ms   Client → SSH_MSG_CHANNEL_REQUEST ("pty-req")
t=19ms   Server → SSH_MSG_CHANNEL_SUCCESS
t=20ms   Client → SSH_MSG_CHANNEL_REQUEST ("shell")
t=21ms   Server → SSH_MSG_CHANNEL_SUCCESS

t=22ms   ──────────────────────── SHELL PROMPT APPEARS

~22ms, ~20+ TCP segments, 3 protocol layers, 1 shared secret never transmitted.

I remember the first time I tried to understand networking. I was staring at terms like TCP/IP, subnets, DNS, and MAC addresses, and honestly, it felt like reading a foreign language. If you're in that spot right now — staring at a wall of jargon and feeling lost — I want you to know something: networking isn't as hard as people make it sound. It's built on ideas you already understand intuitively.

Every time you open a browser, send a message, or stream a video, you're using a network. You just never had to think about how it works. This guide is going to change that.

I'm writing this the way I wish someone had explained networking to me — no unnecessary academic fluff, no skipping over the "obvious" parts that aren't obvious when you're starting out, and plenty of real examples you can try on your own machine.

Let's get into it.

Table of Contents

1. What Even Is a Network?

2. Types of Networks — And Why You Should Care

3. Network Topologies — How Devices Are Arranged

4. Network Devices — The Hardware That Makes It All Work

5. Bandwidth, Latency, and Throughput — The Three Metrics Everyone Confuses

6. The OSI Model — The Mental Map That Makes Everything Click

7. TCP/IP — The Real-World Protocol Stack

8. Data Encapsulation — How Data Gets Wrapped for Travel

9. IP Addresses — Your Device's Identity on the Network

10. Subnetting — Carving Up Networks (With the Binary Math)

11. MAC Addresses and ARP — The Physical Side of Networking

12. Unicast, Broadcast, and Multicast — Three Ways to Deliver Data

13. DNS — The Internet's Phone Book

14. Ports and Protocols — How Applications Talk

15. TCP vs UDP — The Two Ways to Send Data

16. ICMP — The Network's Diagnostic Language

17. DHCP — How Your Device Gets an IP Automatically

18. NAT — How Your Entire House Shares One Public IP

19. Routing — How Data Finds Its Way Across the Internet

20. Firewalls and Proxy Servers — Gatekeepers of the Network

21. HTTP, HTTPS, and the Modern Web (HTTP/2, HTTP/3)

22. TLS — The Encryption That Secures the Internet

23. Practical Networking Commands — Your Complete Toolkit

24. Wireshark — Seeing Network Traffic With Your Own Eyes

25. Troubleshooting Like a Pro — Systematic Debugging

26. Building Your Home Lab

27. Glossary

28. Resources and Next Steps

1. What Even Is a Network?

A network is two or more devices connected together so they can share information. That's the whole definition.

Your phone talking to your Wi-Fi router? That's a network. Two laptops connected with an Ethernet cable? Also a network. Billions of devices connected across the globe through undersea cables, satellites, and fiber optics? That's the internet — the biggest network ever built — but at its core, it follows the same basic principles as those two laptops connected by a cable.

Here's an analogy that I think works well. Think of a network like a postal system:

• Addresses so the system knows where to deliver things (IP addresses)

• Envelopes to package the data (packets)

• Post offices and sorting centers that move things along (routers and switches)

• Rules about how mail should be formatted (protocols)

Networking is really just a set of agreements and systems that let devices send "digital mail" to each other. Everything else in this guide is just the details of those agreements.

A Quick Experiment You Can Do Right Now

Open a terminal (Command Prompt on Windows, Terminal on Mac/Linux) and type:

ping google.com

You'll see something like:

PING google.com (142.250.190.78): 56 data bytes
64 bytes from 142.250.190.78: icmp_seq=0 ttl=117 time=12.3 ms
64 bytes from 142.250.190.78: icmp_seq=1 ttl=117 time=11.8 ms

What just happened? Your computer sent a tiny packet of data to Google's servers and measured how long it took to get a response. That round-trip time (12.3 ms) means the data traveled from your machine to Google and back in about twelve thousandths of a second. You just used the network — and now you can see it working.

2. Types of Networks

Not all networks are the same size or serve the same purpose. Here's a breakdown of the ones you'll encounter most.

LAN (Local Area Network) — The network inside your home or office. Your laptop, phone, smart TV, and printer all connected to your Wi-Fi router form a LAN. It's small, fast, and under your control. Typical speeds: 100 Mbps to 10 Gbps. Typical range: a single building.

WAN (Wide Area Network) — Connects LANs across large geographical distances. The internet itself is the biggest WAN in existence. When your home LAN connects to your friend's home LAN through the internet, that's WAN territory. Your ISP provides the WAN link from your home to the wider internet.

WLAN (Wireless LAN) — A LAN that uses Wi-Fi instead of cables. Most home networks today are WLANs. They follow the IEEE 802.11 standards (you'll see names like Wi-Fi 5, Wi-Fi 6, Wi-Fi 6E, Wi-Fi 7 — each one faster and more capable than the last).

MAN (Metropolitan Area Network) — City-scale networks. A university campus spread across a city or a municipal Wi-Fi system. You won't deal with this much as a beginner, but knowing the term exists is useful.

VPN (Virtual Private Network) — Creates an encrypted tunnel over the public internet, making it look like you're on a private network even though your traffic traverses the public internet. Think of it as sending your postal mail inside a locked box that only the intended recipient can open.

Why This Matters in Practice

When someone says "I need to troubleshoot a network issue," the first question should always be: what kind of network are we talking about? A problem on your home LAN (your printer can't connect) is a completely different investigation than a WAN issue (your ISP is having an outage). Understanding the scope of the network narrows down the problem immediately.

3. Network Topologies

Before we talk about what devices do, let's talk about how they're arranged. The physical or logical layout of a network is called its topology.

Star Topology — The most common layout today. Every device connects to a central device (usually a switch or router). If one device fails, the rest keep working. But if the central device dies, everything goes down. Your home network is a star topology — every device connects to your router.

Bus Topology — All devices share a single cable (the "bus"). Data sent by one device is received by all devices, but only the intended recipient processes it. Old-school Ethernet (10BASE2, 10BASE5) used this. It's cheap and simple but terrible for performance and troubleshooting. If the cable breaks anywhere, the whole network goes down.

Ring Topology — Devices form a loop. Data travels in one direction around the ring, passing through each device until it reaches the destination. Token Ring networks used this. The weakness: one broken link can take down the whole ring (though dual-ring designs mitigate this).

Mesh Topology — Every device connects to every other device. Maximum redundancy — if one link fails, data finds another path. The internet's backbone is a mesh (partially — it's called a "partial mesh" because not every router connects to every other router, but there are multiple redundant paths). Full mesh is expensive and complex, so it's mostly used for critical infrastructure.

Hybrid Topology — Most real-world networks mix topologies. Your office might use a star topology within each floor, connected by a bus (backbone cable) running vertically through the building. The internet is a massive hybrid of mesh, star, and everything in between.

Why This Matters

Understanding topology helps you predict failure modes. In a star topology, you know the switch is the single point of failure. In a mesh, you know the network can survive link failures. When you're designing or troubleshooting a network, topology is one of the first things to consider.

4. Network Devices

Here's something the first draft completely skipped: the actual hardware. You need to understand what these devices do before diving into protocols.

Hub (Mostly Extinct)

A hub is the simplest network device. It receives data on one port and blindly broadcasts it out of every other port. It has no intelligence — it doesn't look at addresses or make decisions. Every device on a hub sees every packet, which creates collisions and wastes bandwidth.

You won't encounter hubs in modern networks. They've been entirely replaced by switches. But knowing what a hub is helps you understand why switches exist.

Switch

A switch is the smart version of a hub. It operates at Layer 2 (Data Link) and uses MAC addresses to forward data only to the specific port where the destination device is connected.

Here's the key difference: when your laptop sends data to the printer, a hub blasts that data to every device. A switch knows the printer is on port 5 and sends the data only to port 5. This is vastly more efficient.

Switches maintain a MAC address table (also called a CAM table) that maps MAC addresses to physical ports. They learn this table automatically by observing the source MAC address of frames arriving on each port.

Managed switches add features like VLANs (virtual LANs), port mirroring, QoS (Quality of Service), and spanning tree protocol. These are what you'll find in business networks.

Router

A router operates at Layer 3 (Network) and connects different networks together. While a switch handles traffic within a single network, a router decides how to move data between networks.

Your home router is the border between your private LAN (192.168.1.x) and the public internet. It has at least two interfaces: one facing your LAN and one facing your ISP. When you visit a website, your router forwards your data from your LAN to your ISP's network, and so on until it reaches the destination.

Routers use routing tables to make forwarding decisions. They work with IP addresses, not MAC addresses.

Access Point (AP)

An access point provides Wi-Fi connectivity. It bridges wireless devices into a wired network. Your home "router" is actually three devices in one: a router, a switch (the Ethernet ports on the back), and an access point (the Wi-Fi radio).

In enterprise environments, these are separate devices. An office building might have dozens of access points managed by a central controller, all providing seamless Wi-Fi as you walk around.

Modem

A modem (modulator-demodulator) converts signals between your ISP's network and your home network. If your ISP uses cable, your cable modem converts cable signals to Ethernet. If it's fiber, the ONT (Optical Network Terminal) does the same for light signals.

Many ISPs provide a combo device (modem + router + AP in one box). Networking enthusiasts often prefer separate devices for more control.

The Device Hierarchy in Your Home

Internet → ISP → Modem → Router → Switch → Your Devices
                           ↓
                     Access Point → Wireless Devices

Understanding this chain is critical for troubleshooting. If only your wireless devices have issues, the problem is likely at the AP level. If nothing has internet, it might be the modem or ISP.

5. Bandwidth, Latency, and Throughput

These three terms are among the most confused in networking. Let's clear this up once and for all.

Bandwidth is the maximum capacity of a connection — how much data could theoretically flow through it per second. It's like the diameter of a water pipe. A 100 Mbps Ethernet connection has a bandwidth of 100 megabits per second. This is the theoretical ceiling, not what you actually get.

Latency is the time it takes for a single piece of data to travel from source to destination. It's measured in milliseconds (ms). When you ping a server and see time=12.3 ms, that's the round-trip latency. Latency is affected by physical distance, the number of hops (routers) in the path, and processing time at each hop.

Throughput is the actual amount of data successfully transferred per second in practice. It's always less than bandwidth because of protocol overhead, congestion, packet loss, and other real-world factors. If your connection has 100 Mbps bandwidth, your actual throughput might be 85 Mbps.

The Highway Analogy

Think of a highway:

• Bandwidth = the number of lanes (capacity)

• Latency = the speed limit + how long the highway is (travel time)

• Throughput = the actual number of cars getting through per hour (accounting for traffic, accidents, toll booths)

A 6-lane highway (high bandwidth) doesn't help if there's a traffic jam (congestion/packet loss). And a 2-lane highway with no traffic (low bandwidth, low latency) might give you better throughput than a congested 6-lane one.

Why This Matters

Online gaming cares most about latency — you need fast response times. Streaming video cares most about throughput — you need sustained data flow. A video conference call cares about both — low latency for real-time interaction, and enough throughput for the video stream.

When someone says "my internet is slow," they could mean high latency (things take time to load), low throughput (downloads are slow), or packet loss (things are glitchy and dropping). The fix is different for each.

Measuring All Three

# Measure latency (round-trip time)
ping -c 10 google.com

# Measure throughput (download/upload speed)
# Install speedtest-cli
speedtest-cli

# Or use curl to measure download speed
curl -o /dev/null -w "Speed: %{speed_download} bytes/sec\n" https://speed.cloudflare.com/__down?bytes=10000000

# Measure path latency at each hop
mtr google.com          # Combines ping + traceroute (install if needed)

The mtr command is one of the most underrated networking tools. It continuously pings every hop along the route, showing you packet loss and latency at each point. If you install one new tool after reading this guide, make it mtr.

6. The OSI Model

The OSI model breaks networking into 7 layers. Each layer has a specific job, and each layer only talks to the layers directly above and below it. Think of it like an assembly line — each station does one thing and passes the work along.

I know this sounds academic. Stay with me — once this clicks, troubleshooting becomes systematic instead of guesswork.

Layer 1: Physical

The actual physical stuff — copper wires, fiber optic cables, radio waves (Wi-Fi), the electrical signals running through them. This layer defines voltages, pin layouts, cable specifications, and how bits are represented as physical signals.

Devices: Cables, hubs, repeaters, network interface cards What can go wrong: Unplugged cable, damaged cable, interference on Wi-Fi, faulty network port

Real example: If your internet isn't working and you notice the Ethernet cable is unplugged — that's a Layer 1 problem. If your Wi-Fi is dropping because your microwave is interfering with the 2.4 GHz band — also Layer 1.

Layer 2: Data Link

Handles communication between devices on the same local network. It uses MAC addresses to identify devices and organizes data into frames. This layer also handles error detection (using CRC checksums on frames) and flow control on the local segment.

Devices: Switches, bridges Protocols: Ethernet (802.3), Wi-Fi (802.11), ARP What can go wrong: MAC address conflicts, switch port misconfiguration, spanning tree loops

Real example: When your laptop sends data to your printer on the same network, Layer 2 uses the printer's MAC address to deliver the frame through the switch to the correct port.

Layer 3: Network

The routing layer. Uses IP addresses to figure out how to get data from one network to another. This is the layer that makes the internet possible — it's what lets your data travel from your home to a server on another continent.

Devices: Routers, Layer 3 switches Protocols: IP (IPv4, IPv6), ICMP, OSPF, BGP What can go wrong: Wrong IP address, incorrect subnet mask, routing table errors, gateway misconfiguration

Real example: When you type google.com, your data needs to cross multiple networks. Layer 3 routers at each hop examine the destination IP and decide where to forward the packet next.

Layer 4: Transport

Ensures reliable (or fast) delivery of data end-to-end. It breaks data into segments, manages flow control, handles error recovery, and multiplexes multiple applications over a single IP connection using port numbers.

Protocols: TCP (reliable), UDP (fast) What can go wrong: Port blocked by firewall, connection timeouts, congestion

Real example: When you download a file, TCP (at Layer 4) makes sure every piece arrives correctly and in order. If a segment is lost, TCP detects this and requests retransmission.

Layer 5: Session

Manages sessions — ongoing connections between two devices. Handles opening, maintaining, and closing conversations. Also manages checkpointing and recovery (if a large file transfer fails halfway, the session layer can resume from the checkpoint rather than starting over).

Real example: When you log into a website and stay logged in across multiple page loads, a session is being maintained.

Layer 6: Presentation

Handles data translation, encryption, and compression. Makes sure data is in a format the receiving application can understand. Think of it as a translator between different data formats.

Examples: SSL/TLS encryption, JPEG compression, character encoding (ASCII to Unicode conversion)

Real example: When your browser receives gzip-compressed data from a web server, this layer handles the decompression.

Layer 7: Application

The layer closest to the user. Where applications and application-layer protocols operate.

Protocols: HTTP, HTTPS, FTP, SMTP, DNS, SSH, SNMP What can go wrong: Application bugs, misconfigured services, authentication failures

Real example: When you open your browser and visit a website, the HTTP protocol at Layer 7 formats your request and interprets the server's response.

The Mnemonic

Bottom (1) to top (7): Please Do Not Throw Sausage Pizza Away

Why the OSI Model Matters in Practice

It gives you a troubleshooting system. Start from the bottom:

1. Is the cable plugged in? Is Wi-Fi connected? (Layer 1)

2. Can I see other devices on my local network? (Layer 2)

3. Can I ping an IP address on another network? (Layer 3)

4. Can I connect to a specific port on that IP? (Layer 4)

5. Is the application responding correctly? (Layer 7)

This layered approach saves you from randomly guessing what's wrong. You isolate the problem layer, and that tells you where to focus.

7. TCP/IP — The Real-World Protocol Stack

Here's a practical truth: nobody implements the OSI model exactly as described. It's a theoretical framework. What the internet actually runs on is the TCP/IP model, which consolidates those 7 layers into 4 practical ones.

The TCP/IP model is what you'll reference in real-world work. But the OSI model is still incredibly useful as a thinking tool, especially for troubleshooting. That's why everyone still teaches both.

In conversation, people mix the two freely. Someone might say "that's a Layer 2 issue" (OSI language) while working with the TCP/IP stack. Don't let that confuse you — just understand that both models describe the same reality at different levels of detail.

8. Data Encapsulation

This is one of the most important concepts in networking, and visualizing it makes everything else easier to understand.

When your application sends data, it doesn't just shoot raw information across the wire. Each layer of the stack wraps the data with its own header, adding the information that layer needs. This wrapping process is called encapsulation.

Here's what happens when you send a message:

Step 1 — Application Layer: Your application creates the data. Let's say it's an HTTP request: GET /index.html. At this point, it's just called data.

Step 2 — Transport Layer: TCP wraps the data with a TCP header (containing source port, destination port, sequence number, flags). The data is now called a segment.

Step 3 — Network Layer: IP wraps the segment with an IP header (containing source IP, destination IP, TTL, protocol type). It's now called a packet.

Step 4 — Data Link Layer: Ethernet wraps the packet with an Ethernet header (containing source MAC, destination MAC) and adds a trailer (CRC checksum for error detection). It's now called a frame.

Step 5 — Physical Layer: The frame is converted into bits — electrical signals on copper, light pulses on fiber, or radio waves over Wi-Fi.

At the receiving end, the whole process reverses. Each layer strips its header, reads the relevant information, and passes the payload up to the next layer. This is de-encapsulation.

Why This Matters

When you look at a packet in Wireshark, you're literally seeing these layers. The Ethernet header is there. The IP header is inside it. The TCP header is inside that. And the HTTP data is inside that. Understanding encapsulation is what makes packet analysis readable instead of gibberish.

Also, the terminology matters in conversation. If someone says "frame," they're talking about Layer 2 data. "Packet" means Layer 3. "Segment" means Layer 4. Using the right terms makes you sound like you know what you're doing — because you will.

9. IP Addresses

If the network is a postal system, the IP address is the street address. Every device on a network needs one.

IPv4

An IPv4 address looks like this: 192.168.1.10

It's four numbers (called octets) separated by dots. Each octet ranges from 0 to 255. Under the hood, each octet is 8 bits, so an IPv4 address is 32 bits total.

Let's see that in binary, because understanding the binary representation is essential for subnetting later:

  192    .   168    .    1     .    10
11000000 . 10101000 . 00000001 . 00001010

32 bits gives us 2^32 = roughly 4.3 billion possible addresses. That sounded like plenty in the 1980s. With billions of devices on the internet today, we've essentially run out. That's why IPv6 exists and why NAT is so important.

Public vs Private IP Addresses

This trips up beginners constantly, so let me be crystal clear.

Public IP addresses are globally unique. Your ISP assigns one to your home router. This is the address the rest of the internet sees.

Private IP addresses are only unique within your local network. They are not routable on the public internet. Three ranges are reserved for private use (defined in RFC 1918):

When your laptop has IP 192.168.1.10, that address means nothing on the public internet. It only has meaning within your LAN. Your router uses NAT to translate between your private address and the public internet (covered in section 18).

Try It Yourself: Find Your IP Address

Linux:

# Private IP
ip addr show | grep "inet "

# Public IP
curl -s ifconfig.me

Mac:

# Private IP
ifconfig | grep "inet "

# Public IP
curl -s ifconfig.me

Windows:

REM Private IP
ipconfig

REM Public IP — open browser and visit:
REM https://whatismyipaddress.com

You'll notice your private IP is something like 192.168.x.x, while your public IP is completely different.

IPv6

IPv6 was created to solve address exhaustion. An IPv6 address is 128 bits long:

2001:0db8:85a3:0000:0000:8a2e:0370:7334

That gives roughly 340 undecillion addresses (3.4 × 10^38). Enough for every grain of sand on Earth to have its own IP address trillions of times over.

IPv6 can be shortened by dropping leading zeros and replacing consecutive groups of all-zeros with :::

2001:0db8:85a3:0000:0000:8a2e:0370:7334
becomes:
2001:db8:85a3::8a2e:370:7334

IPv6 adoption has been growing steadily (Google reports over 45% of its traffic is now IPv6), but IPv4 still dominates in practice. As a beginner, master IPv4 first. The jump to IPv6 is mostly about the longer address format and some protocol differences (IPv6 has no broadcast — it uses multicast instead, and no NAT by design since there are enough addresses for everyone).

Special IP Addresses Worth Memorizing

10. Subnetting

This is the topic that makes most beginners want to quit networking. I'm going to teach it differently — starting with the binary math that makes it intuitive, rather than asking you to memorize tables.

What Is a Subnet?

A subnet is a logical division of an IP network. If an IP address is a street address, the subnet is the neighborhood. Subnetting lets you carve a large network into smaller, manageable pieces. It also controls which devices can communicate directly (same subnet) versus which need a router (different subnets).

The Subnet Mask — In Binary

Every IP address comes paired with a subnet mask. The mask tells you which bits of the IP identify the network and which identify the host (specific device).

IP Address:     192.168.1.10
Subnet Mask:    255.255.255.0

In binary:

IP:     11000000.10101000.00000001.00001010
Mask:   11111111.11111111.11111111.00000000
        |--- Network (24 bits) ---|-- Host -|

The rule is simple: Where the mask has a 1, that bit belongs to the network portion. Where it has a 0, that bit belongs to the host portion.

To find the network address, you AND the IP and mask together (bit by bit):

IP:     11000000.10101000.00000001.00001010  (192.168.1.10)
Mask:   11111111.11111111.11111111.00000000  (255.255.255.0)
AND:    11000000.10101000.00000001.00000000  (192.168.1.0) ← Network address

Any device whose IP ANDs to the same network address is on the same subnet.

CIDR Notation

Instead of writing the full mask, we use a slash and the count of network bits:

192.168.1.10/24

The /24 means the first 24 bits are the network portion — equivalent to 255.255.255.0.

The Math: How Many Hosts?

The number of host bits determines how many devices the subnet can hold:

Usable hosts = 2^(host bits) - 2

We subtract 2 because one address is reserved for the network address (all host bits = 0) and one for the broadcast address (all host bits = 1).

Subnetting Step by Step: A Real Example

The scenario: You have the network 10.0.1.0/24 and need to create subnets for:

• Engineering: 50 devices

• Marketing: 20 devices

• Management: 10 devices

Step 1 — Engineer's subnet (50 devices):

You need at least 50 hosts. Find the smallest subnet that fits:

• /26 = 62 hosts ✓ (6 host bits: 2^6 - 2 = 62)

• /27 = 30 hosts ✗ (too small)

Assign: 10.0.1.0/26

• Network: 10.0.1.0

• First host: 10.0.1.1

• Last host: 10.0.1.62

• Broadcast: 10.0.1.63

Step 2 — Marketing's subnet (20 devices):

Next available block starts at 10.0.1.64.

• /27 = 30 hosts ✓

Assign: 10.0.1.64/27

• Network: 10.0.1.64

• First host: 10.0.1.65

• Last host: 10.0.1.94

• Broadcast: 10.0.1.95

Step 3 — Management's subnet (10 devices):

Next block starts at 10.0.1.96.

• /28 = 14 hosts ✓

Assign: 10.0.1.96/28

• Network: 10.0.1.96

• First host: 10.0.1.97

• Last host: 10.0.1.110

• Broadcast: 10.0.1.111

Now each team has its own subnet, traffic between them requires routing (which lets you apply access controls), and you're not wasting addresses.

Try It Yourself

# Check your current subnet on Linux
ip addr show
# Look for something like: inet 192.168.1.10/24

# Use ipcalc for quick subnet calculations (install if needed)
ipcalc 10.0.1.0/26
# Shows network, broadcast, host range, etc.

11. MAC Addresses and ARP

What's a MAC Address?

Every network interface card (NIC) — your laptop's Wi-Fi chip, your Ethernet port, your phone's wireless adapter — ships with a MAC (Media Access Control) address assigned at the factory. It's a 48-bit address written as six pairs of hexadecimal digits:

a4:83:e7:2f:10:b5

The first three pairs (a4:83:e7) are the OUI (Organizationally Unique Identifier) — they identify the manufacturer. The last three pairs are a unique serial assigned by that manufacturer. In theory, no two NICs in the world share a MAC address (though in practice, MAC addresses can be spoofed or changed in software).

IP address vs MAC address: Your IP address is like your mailing address — it changes when you move. Your MAC address is like a serial number stamped on your network card — it's tied to the hardware.

Where MAC Addresses Are Used

MAC addresses only matter at Layer 2 on the local network. When your laptop sends data to your printer on the same subnet, the Ethernet frame uses MAC addresses to deliver it through the switch.

Here's the critical part: MAC addresses don't survive routing. When a frame leaves your network and hits a router, the router strips the Layer 2 header (your MAC and the router's MAC) and creates a new one for the next hop. The IP addresses stay the same end-to-end, but MAC addresses change at every router hop.

ARP — Bridging IP and MAC

Here's the problem: your application knows the destination IP (192.168.1.20 — the printer), but Layer 2 needs a MAC address to deliver the frame. How does your machine find the MAC address for that IP?

ARP (Address Resolution Protocol) solves this.

1. Your machine broadcasts an ARP Request to every device on the local network: "Who has IP 192.168.1.20? Tell 192.168.1.10 (me)."

2. Every device receives this broadcast, but only the device with IP 192.168.1.20 responds.

3. That device sends an ARP Reply directly back: "I have 192.168.1.20, and my MAC is a4:83:e7:2f:10:b5."

4. Your machine stores this mapping in its ARP cache so it doesn't have to ask again for a while.

Try It Yourself

# View your ARP cache (all platforms)
arp -a

# Linux — more detailed view
ip neigh show

# Watch ARP in real-time with tcpdump
sudo tcpdump -i any arp

# Then ping a device you haven't communicated with recently
# and watch the ARP request/reply in the tcpdump output

ARP Spoofing — Why This Matters for Security

ARP has no authentication. Any device can claim to be any IP address. An attacker on your local network can send fake ARP replies, associating their MAC address with your gateway's IP. This redirects your traffic through the attacker's machine — a classic man-in-the-middle attack. This is one reason why HTTPS (which encrypts data end-to-end) is so important, and why you shouldn't trust open Wi-Fi networks.

12. Unicast, Broadcast, and Multicast

There are three fundamental ways to deliver data on a network. Understanding these clarifies a lot of other concepts.

Unicast — One-to-one. Data is sent from one source to one specific destination. When you browse a website, your connection to the web server is unicast. Most network traffic is unicast.

Broadcast — One-to-all. Data is sent to every device on the local network. ARP requests are broadcasts. DHCP discovery is a broadcast. Broadcasts don't cross routers — they stay within the local subnet (this boundary is called the broadcast domain).

Multicast — One-to-many (but not all). Data is sent to a group of interested devices. Instead of sending the same video stream 100 times (unicast to each viewer), a streaming service can send it once as multicast, and only devices that subscribed to that multicast group receive it. IPTV and some enterprise video conferencing use multicast.

Why Broadcasts Are a Problem

Every broadcast packet must be processed by every device on the network, even if most devices don't care about it. In a large flat network with thousands of devices, broadcast traffic can consume significant bandwidth and CPU time — this is called a broadcast storm in the worst case. This is one of the key reasons networks are divided into subnets — each subnet is its own broadcast domain, limiting the blast radius of broadcasts.

13. DNS — The Internet's Phone Book

This is one of my favorite topics because once you understand DNS, you suddenly understand why "the internet is slow" can mean very different things.

The Problem

Humans remember names. Computers use numbers. DNS (Domain Name System) translates google.com into 142.250.190.78 so you don't have to memorize IP addresses.

How a DNS Lookup Works

Let's trace what happens when you type www.example.com:

Step 1 — Check local caches. Your browser has a cache. Your OS has a cache. If a recent lookup exists, it uses that immediately — no network request needed.

Step 2 — Query the recursive resolver. Cache miss? Your computer asks a recursive resolver (usually provided by your ISP, or a public one like 8.8.8.8 from Google or 1.1.1.1 from Cloudflare). This resolver does all the heavy lifting.

Step 3 — Root name servers. The resolver asks a root name server (there are 13 clusters, operated by different organizations around the world). The root doesn't know the answer, but knows who handles .com domains.

Step 4 — TLD name servers. The .com TLD (Top-Level Domain) server doesn't know example.com's IP either, but knows which authoritative name server handles example.com.

Step 5 — Authoritative name server. This server has the actual DNS records for example.com. It responds: "The A record for www.example.com is 93.184.216.34."

Step 6 — Response delivered. The resolver passes the IP back to your computer, caching it along the way. Your browser can now connect.

This entire hierarchy of queries typically resolves in 20-80 milliseconds. And thanks to caching at every level, most lookups are nearly instant.

DNS Record Types

DNS stores multiple types of records:

Try It Yourself

# Basic lookup
nslookup example.com

# Detailed lookup with dig
dig example.com

# Query specific record types
dig example.com MX
dig example.com TXT
dig example.com NS

# Trace the full resolution path (fascinating to watch)
dig +trace example.com

# Use a specific DNS server
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

# Reverse DNS lookup
dig -x 93.184.216.34

# Check which DNS server your system uses (Linux)
cat /etc/resolv.conf

# Check DNS resolution time
time dig example.com

Common DNS Issues and Fixes

"DNS_PROBE_FINISHED_NXDOMAIN" — The domain doesn't exist (or your DNS can't find it).

# Step 1: Flush DNS cache
sudo systemd-resolve --flush-caches    # Linux (systemd)
sudo dscacheutil -flushcache            # Mac
ipconfig /flushdns                      # Windows

# Step 2: Test with a different DNS server
dig @8.8.8.8 the-failing-domain.com

# Step 3: If it works with 8.8.8.8 but not your default,
#          change your DNS server to 8.8.8.8 or 1.1.1.1

A Note on DNS Security

Standard DNS queries travel in plain text. Anyone between you and the resolver can see what domains you're looking up. This is a privacy concern. Modern solutions include:

• DNS over HTTPS (DoH) — Encrypts DNS queries inside HTTPS. Firefox and Chrome support this.

• DNS over TLS (DoT) — Encrypts DNS queries using TLS. Android supports this natively.

• DNSSEC — Doesn't encrypt queries, but signs DNS responses so you can verify they haven't been tampered with. Prevents DNS spoofing attacks.

14. Ports and Protocols

If an IP address gets data to the right building (the device), a port gets it to the right apartment (the application) inside that building.

What's a Port?

A port is a 16-bit number (0–65535) that identifies a specific application or service. When your computer receives data, the port tells the OS which application should handle it.

Port Ranges

Essential Port Numbers

Sockets — The Full Picture

A socket is the combination of IP + port. A complete network connection is identified by a 5-tuple:

(Protocol, Source IP, Source Port, Destination IP, Destination Port)

Example:

(TCP, 192.168.1.10, 52431, 142.250.190.78, 443)

This uniquely identifies one specific conversation between your browser and Google's server. Your browser can have dozens of simultaneous connections to different servers (or even the same server on different ports), and each one has a unique 5-tuple.

Try It Yourself

# See all listening ports and which programs are using them
ss -tulnp               # Linux
netstat -tulnp           # Linux (older)
netstat -an | grep LISTEN # Mac
netstat -an              # Windows

# Check if a specific port is open on a remote host
nc -zv google.com 443
nc -zv google.com 80

# See which process is using a specific port
sudo lsof -i :80        # Mac/Linux

15. TCP vs UDP

Both live at Layer 4 (Transport), but they represent two fundamentally different philosophies of data delivery.

TCP — Transmission Control Protocol

TCP is the "reliable" protocol. It guarantees data arrives correctly, completely, and in order.

The Three-Way Handshake (Connection Setup):

1. SYN: Client → Server. "I want to connect." (Sends a synchronize packet with a random sequence number.)

2. SYN-ACK: Server → Client. "Okay, I acknowledge your SYN. Here's my sequence number too."

3. ACK: Client → Server. "Got it. Connection established."

The Four-Way Teardown (Connection Close):

This is what the first draft completely missed. Closing a TCP connection also follows a formal process:

1. FIN: Side A says "I'm done sending."

2. ACK: Side B acknowledges. (Side B might still have data to send.)

3. FIN: Side B says "I'm done too."

4. ACK: Side A acknowledges. Connection fully closed.

This four-step close exists because TCP connections are bidirectional — each side independently closes its sending half.

TCP's Reliability Mechanisms:

• Sequence numbers: Every byte of data gets a sequence number. The receiver knows exactly what order to reassemble.

• Acknowledgments: The receiver confirms what it got. If the sender doesn't get an ACK within a timeout, it retransmits.

• Checksums: Each segment includes a checksum to detect corruption.

• Flow control (Window Size): The receiver tells the sender how much data it can handle, preventing overwhelming a slow receiver.

• Congestion control: TCP detects network congestion (packet loss) and slows down to reduce it (algorithms like slow start, congestion avoidance, fast retransmit).

UDP — User Datagram Protocol

UDP is the "fast and lean" protocol. No connection setup. No guarantees. It just sends datagrams.

What UDP doesn't do:

• No handshake — sends immediately

• No acknowledgments — doesn't know if data arrived

• No ordering — packets may arrive out of sequence

• No congestion control — sends as fast as it can

What UDP offers:

• Minimal overhead (8-byte header vs TCP's 20+ bytes)

• Lower latency (no handshake delay)

• No head-of-line blocking (one lost packet doesn't stall the rest)

• Supports broadcast and multicast

When to Use Which

The Comparison

TCP is a phone call. Dial, wait for pickup, talk with confirmation, hang up properly.

UDP is shouting across a field. Fast, no waiting, but maybe they didn't hear you.

16. ICMP — The Network's Diagnostic Language

ICMP (Internet Control Message Protocol) lives at Layer 3 and serves as the network's error reporting and diagnostic system. You've already used it — every time you run ping, you're sending ICMP messages.

Key ICMP Message Types

How Traceroute Uses ICMP

traceroute exploits ICMP's Time Exceeded message. It sends packets with increasing TTL (Time To Live) values:

1. Sends a packet with TTL=1. The first router decrements TTL to 0, drops the packet, and sends back an ICMP Time Exceeded. Now you know the first hop.

2. Sends a packet with TTL=2. The first router decrements to 1, forwards it. The second router decrements to 0, sends back Time Exceeded. Now you know hop 2.

3. This continues until the packet reaches the destination.

This is why some hops in traceroute output show * * * — those routers are configured to not send ICMP Time Exceeded messages (for security reasons).

ICMP and Security

Many firewalls block ICMP. This is why ping sometimes fails even when a server is perfectly reachable via HTTP. A failed ping doesn't always mean the host is down — it might just mean ICMP is blocked.

17. DHCP — How Your Device Gets an IP Automatically

When you connect your phone to Wi-Fi and it "just works" without manual configuration, DHCP is responsible.

The DHCP Process (DORA)

1. Discover — Your device broadcasts: "Is there a DHCP server? I need an IP address!" (UDP broadcast to 255.255.255.255)

2. Offer — The DHCP server responds: "Here's 192.168.1.25. Gateway is 192.168.1.1, DNS is 8.8.8.8, lease is 24 hours."

3. Request — Your device replies: "I'll take 192.168.1.25, please."

4. Acknowledge — Server confirms: "Done. It's yours for 24 hours."

The lease concept is key. Your device borrows the IP for a set period. Before the lease expires, your device automatically attempts to renew. If you disconnect and the lease expires, the address returns to the pool.

What DHCP Provides

DHCP assigns more than just an IP address:

• IP address

• Subnet mask

• Default gateway

• DNS server(s)

• Lease duration

• Optionally: NTP servers, domain name, TFTP server (for network booting), and more

Static vs Dynamic IP Assignment

Dynamic (DHCP): Address can change. Fine for laptops, phones, and most devices.

Static: Manually assigned permanent address. Essential for servers, printers, network devices, and anything other devices need to find reliably.

DHCP Reservation: A hybrid approach — the DHCP server always assigns the same IP to a specific MAC address. The device still uses DHCP, but gets a consistent address. This is often the best approach for home lab servers and printers.

Try It Yourself

# Release and renew on Linux
sudo dhclient -r eth0        # Release
sudo dhclient eth0            # Renew

# On Windows
ipconfig /release
ipconfig /renew

# Check your lease info (Linux)
cat /var/lib/dhcp/dhclient.leases

18. NAT — How Your Entire House Shares One Public IP

The Problem

Your ISP gives you one public IP address. You have 15+ devices that need internet. How?

How NAT Works

NAT (Network Address Translation), running on your router, maintains a translation table that maps each internal device's private IP and port to the router's single public IP with a unique port.

Your laptop visits a website:

Laptop: 192.168.1.10:52431
  → Router NAT → 203.0.113.5:12001
    → Internet → Web Server

Response from Web Server
  → 203.0.113.5:12001
    → Router NAT → 192.168.1.10:52431
      → Laptop

Your phone, simultaneously:

Phone: 192.168.1.11:48922
  → Router NAT → 203.0.113.5:12002
    → Internet

Response → 203.0.113.5:12002
  → Router NAT → 192.168.1.11:48922
    → Phone

The router uses different external port numbers to track which internal device made which request. This is technically PAT (Port Address Translation), though most people just call it NAT.

Why NAT Has Been Both a Savior and a Headache

Benefits:

• Conserves IPv4 addresses (billions of devices share millions of public IPs)

• Provides a basic layer of security (unsolicited inbound connections are dropped by default since the router doesn't know where to forward them)

Drawbacks:

• Breaks end-to-end connectivity (external devices can't initiate connections to your devices)

• Complicates hosting services from home (you need port forwarding)

• Breaks some protocols that embed IP addresses in their payload

• Adds latency (translation takes time)

• Makes peer-to-peer connections harder (both sides are behind NAT)

Port forwarding is the workaround for hosting services: you tell the router "any traffic arriving on external port 8080 should be forwarded to internal device 192.168.1.100 port 80." This is how people run home servers, game servers, and security cameras accessible from outside.

19. Routing — How Data Finds Its Way

When you send data to a server on another continent, it doesn't teleport. It hops through multiple routers, each making a decision about the next step. This decision-making is routing.

How It Works

Every router has a routing table — a list of known networks and the "next hop" to reach each one. When a packet arrives, the router:

1. Reads the destination IP address

2. Checks its routing table for the best matching route

3. Forwards the packet to the next hop

4. The next router repeats the process

No single router knows the complete path to the destination. Each router only knows the next step. It's like asking for directions in an unfamiliar city — each person you ask knows their local area and points you to the next landmark.

Try It Yourself

# See every hop to the destination
traceroute google.com        # Linux/Mac
tracert google.com           # Windows

# Better: use mtr for continuous monitoring
mtr google.com               # Shows packet loss per hop in real-time

# Check your machine's routing table
ip route show                 # Linux
netstat -rn                   # Mac
route print                   # Windows

traceroute output explained:

 1  192.168.1.1      1.2 ms     ← Your home router
 2  10.0.0.1         8.4 ms     ← ISP's first router
 3  72.14.215.85    11.7 ms     ← Backbone router
 4  108.170.252.129 12.0 ms     ← Getting closer
 5  142.250.190.78  12.3 ms     ← Destination (Google)

Static vs Dynamic Routing

Static routing: Administrator manually enters routes. Fine for simple, small networks. Doesn't adapt to failures.

Dynamic routing: Routers automatically discover and share route information using protocols:

• OSPF (Open Shortest Path First): Used within organizations. Routers build a complete map of the network topology and calculate shortest paths using Dijkstra's algorithm.

• BGP (Border Gateway Protocol): The protocol that runs the internet. Manages routing between autonomous systems (AS) — large networks operated by ISPs, cloud providers, and enterprises. When you hear about "internet routing," you're hearing about BGP.

The Default Gateway

Your device's default gateway (usually your home router, like 192.168.1.1) is the "if I don't know where this goes, send it here" address. For any destination not on your local subnet, your machine sends the packet to the default gateway and trusts the router to figure out the rest.

# Check your default gateway
ip route show default         # Linux
netstat -nr | grep default    # Mac
ipconfig | findstr "Gateway"  # Windows

20. Firewalls and Proxy Servers

Firewalls

A firewall controls what traffic is allowed into and out of a network or device by examining packets against a set of rules.

Packet filtering firewall: The simplest type. Examines headers (source/destination IP, port, protocol) and allows or blocks based on rules. Stateless — treats each packet independently.

Stateful firewall: Tracks connection state. If your machine initiates a connection to a web server, the firewall remembers and automatically allows the response. But unsolicited inbound connections get blocked. Most modern firewalls are stateful.

Application-layer firewall / WAF (Web Application Firewall): Inspects Layer 7 content. Can block malicious HTTP requests, prevent SQL injection, and filter based on URL patterns or request bodies. Used to protect web applications.

Linux Firewall in Practice

# iptables — traditional Linux firewall
sudo iptables -L -v -n                             # View current rules

# Allow established connections (most important rule)
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH, HTTP, HTTPS
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Allow ICMP (ping)
sudo iptables -A INPUT -p icmp -j ACCEPT

# Allow loopback
sudo iptables -A INPUT -i lo -j ACCEPT

# Block everything else
sudo iptables -A INPUT -j DROP

UFW — the friendly alternative:

sudo ufw enable
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status verbose

Proxy Servers — The Missing Topic

A proxy server sits between your device and the internet, acting as an intermediary.

Forward proxy: Sits between internal clients and the internet. Your request goes to the proxy, which makes the request on your behalf. Uses: privacy (the destination sees the proxy's IP, not yours), content filtering (corporate networks blocking certain sites), caching (commonly requested content is stored locally).

Reverse proxy: Sits between the internet and your servers. External requests hit the reverse proxy, which forwards them to the appropriate internal server. Uses: load balancing (distributing traffic across multiple servers), SSL termination (handling TLS encryption), caching, security (hiding internal server architecture). Nginx and HAProxy are popular reverse proxies.

Transparent proxy: Intercepts traffic without the client's knowledge. ISPs sometimes use these for caching. Corporate networks use them for content filtering.

21. HTTP, HTTPS, and the Modern Web

HTTP Basics

HTTP (HyperText Transfer Protocol) is the protocol that powers the web. It's a request-response protocol: your browser sends a request, the server sends a response.

An HTTP request:

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

Key HTTP methods:

(Idempotent means calling it multiple times produces the same result as calling it once.)

HTTP Status Codes

HTTP/1.1 vs HTTP/2 vs HTTP/3

HTTP/1.1 (1997): One request per TCP connection at a time (or with keep-alive, sequential requests). To load a page with 50 resources, browsers open 6+ parallel TCP connections. Head-of-line blocking is a major problem — one slow response blocks everything behind it on that connection.

HTTP/2 (2015): Multiplexing — multiple requests and responses flow simultaneously over a single TCP connection using binary frames. Header compression (HPACK) reduces overhead. Server push allows the server to send resources before the browser asks for them. Major performance improvement. However, TCP-level head-of-line blocking still exists — if a single TCP packet is lost, all streams on that connection stall until retransmission.

HTTP/3 (2022): The game changer. Replaces TCP with QUIC (built on UDP). QUIC provides its own reliability and encryption (TLS 1.3 is built-in), and eliminates TCP's head-of-line blocking — a lost packet only affects its specific stream, not others. Connection migration means if your phone switches from Wi-Fi to cellular, the connection doesn't break. Most major websites now support HTTP/3.

Try It Yourself

# See full HTTP conversation
curl -v https://example.com

# See response headers only
curl -I https://example.com

# Check which HTTP version a site uses
curl -sI https://www.google.com | grep -i "http/"

# Make a POST request with JSON
curl -X POST https://httpbin.org/post \
  -H "Content-Type: application/json" \
  -d '{"name": "test", "value": 42}'

# Follow redirects
curl -L -I http://google.com     # Watch the 301 → 200

# Measure timing breakdown
curl -w "\n  DNS: %{time_namelookup}s\n  Connect: %{time_connect}s\n  TLS: %{time_appconnect}s\n  Start Transfer: %{time_starttransfer}s\n  Total: %{time_total}s\n" -o /dev/null -s https://example.com

That last curl command is incredibly powerful for diagnosing performance — it shows exactly where time is spent (DNS resolution, TCP connection, TLS handshake, server processing, total).

22. TLS — The Encryption That Secures the Internet

TLS (Transport Layer Security) is what puts the "S" in HTTPS. Without it, all web traffic would be plain text readable by anyone on the network path.

TLS 1.3 — The Current Standard

TLS 1.3 (finalized in 2018) made major improvements over TLS 1.2:

Faster handshake: TLS 1.2 required 2 round trips before encrypted data could flow. TLS 1.3 needs only 1 round trip (and supports 0-RTT resumption for returning connections).

Stronger security: Removed support for weak ciphers and algorithms. Only uses AEAD (Authenticated Encryption with Associated Data) cipher suites. No more RSA key exchange (only ephemeral Diffie-Hellman, providing forward secrecy by default).

Simpler: Fewer cipher suite options means fewer ways to misconfigure. TLS 1.3 has 5 cipher suites versus TLS 1.2's 37+.

The TLS 1.3 Handshake (Simplified)

1. Client Hello: Your browser sends supported cipher suites and a key share (Diffie-Hellman parameters).

2. Server Hello: The server picks a cipher suite, sends its key share, its certificate (proving identity), and a Finished message — all in one step.

3. Client Finished: The client verifies the certificate (checking the chain of trust back to a trusted Certificate Authority), computes the shared secret, and sends its Finished message.

4. Encrypted data flows. Both sides now have a shared secret key. All application data is encrypted.

Certificates and the Chain of Trust

When a server presents its TLS certificate, your browser verifies it by checking:

1. Is the certificate for this domain? (Common Name or Subject Alternative Name matches)

2. Is it within its validity period? (Not expired or not-yet-valid)

3. Is it signed by a trusted Certificate Authority? (The CA that signed the cert is in your OS/browser's trusted root store)

4. Is the whole chain valid? (Server cert → Intermediate CA → Root CA, each signing the one below)

5. Has it been revoked? (Checked via CRL or OCSP)

Try It Yourself

# View a site's TLS certificate
openssl s_client -connect example.com:443 -brief

# See the full certificate chain
openssl s_client -connect example.com:443 -showcerts

# Check TLS version negotiated
curl -vI https://example.com 2>&1 | grep "SSL connection"

# Test if a server supports specific TLS versions
openssl s_client -connect example.com:443 -tls1_3

23. Practical Networking Commands — Your Complete Toolkit

This is your go-to reference section. Organized by purpose with coverage across operating systems.

Connectivity Testing

# Basic ping
ping google.com                          # All platforms
ping -c 5 google.com                     # Linux/Mac: send exactly 5
ping -n 5 google.com                     # Windows: send exactly 5

# Ping with timestamp
ping -D google.com                       # Linux: shows Unix timestamp

# Trace the route
traceroute google.com                    # Linux/Mac
tracert google.com                       # Windows

# Best of both: continuous trace + ping
mtr google.com                           # Linux (install: apt install mtr)
mtr --report google.com                  # Generate a report

DNS Tools

# Quick lookup
nslookup example.com                     # All platforms

# Detailed lookup
dig example.com                          # Linux/Mac
dig example.com +short                   # Just the IP
dig example.com ANY                      # All records
dig +trace example.com                   # Full resolution trace
dig @8.8.8.8 example.com                # Query specific server
dig -x 93.184.216.34                     # Reverse lookup

Port and Connection Analysis

# Active connections and listening ports
ss -tulnp                                # Linux (modern)
netstat -tulnp                           # Linux (legacy)
netstat -an | grep LISTEN                # Mac
netstat -an                              # Windows

# Test if a remote port is open
nc -zv google.com 443                    # Linux/Mac
Test-NetConnection google.com -Port 443  # Windows PowerShell

# Which process is using a port?
sudo lsof -i :80                         # Mac/Linux
sudo ss -tulnp | grep :80               # Linux

Network Interface and IP Information

# Your interfaces and IPs
ip addr show                             # Linux (modern)
ifconfig                                 # Mac / older Linux
ipconfig                                 # Windows
ipconfig /all                            # Windows: detailed

# Your public IP
curl -s ifconfig.me                      # Linux/Mac
curl -s icanhazip.com                    # Alternative

# Routing table
ip route show                            # Linux
netstat -rn                              # Mac
route print                              # Windows

HTTP Debugging

# Full conversation (request + response)
curl -v https://example.com

# Headers only
curl -I https://example.com

# Follow redirects
curl -L -I http://google.com

# Download a file
curl -O https://example.com/file.zip

# POST with JSON
curl -X POST https://httpbin.org/post \
  -H "Content-Type: application/json" \
  -d '{"key": "value"}'

# Performance timing
curl -w "DNS:%{time_namelookup} TCP:%{time_connect} TLS:%{time_appconnect} Total:%{time_total}\n" \
  -o /dev/null -s https://example.com

Packet Capture

# Capture all traffic on an interface
sudo tcpdump -i eth0

# Capture only specific traffic
sudo tcpdump -i any port 80                    # HTTP
sudo tcpdump -i any port 53                    # DNS
sudo tcpdump -i any host 192.168.1.10          # Specific host
sudo tcpdump -i any 'tcp[tcpflags] & tcp-syn != 0'  # SYN packets

# Save to file for Wireshark
sudo tcpdump -i any -w capture.pcap

# ARP traffic
sudo tcpdump -i any arp

ARP and MAC

# ARP cache
arp -a                                   # All platforms
ip neigh show                            # Linux (modern)

24. Wireshark — Seeing Network Traffic With Your Own Eyes

Wireshark is a free, open-source packet analyzer that captures and displays all traffic on your network interface. It's the difference between reading about networking and watching it happen.

Getting Started

1. Download from wireshark.org

2. Select your active network interface (Wi-Fi or Ethernet)

3. Click Start Capture

4. Open a website in your browser

5. Go back to Wireshark and watch packets appear in real-time

Essential Display Filters

# By protocol
http
dns
tls
arp
icmp
tcp
udp

# By address
ip.addr == 192.168.1.10                    # Traffic to/from this IP
ip.src == 192.168.1.10                     # Traffic from this IP
ip.dst == 142.250.190.78                   # Traffic to this IP
eth.addr == a4:83:e7:2f:10:b5             # By MAC address

# By port
tcp.port == 443
tcp.port == 80
udp.port == 53

# TCP flags
tcp.flags.syn == 1 && tcp.flags.ack == 0   # SYN only (connection starts)
tcp.flags.fin == 1                          # FIN (connection closes)
tcp.flags.reset == 1                        # RST (connection aborts)

# HTTP specifics
http.request.method == "GET"
http.response.code == 404

# TLS handshake
tls.handshake

# Combine filters
ip.addr == 192.168.1.10 && tcp.port == 80
dns && ip.src == 192.168.1.10

Guided Exercise: Watch a Full Web Request

1. Start a capture in Wireshark

2. Open your browser and visit http://example.com (HTTP, not HTTPS — so you can see the content)

3. Stop the capture

4. Apply filter: ip.addr == 93.184.216.34 (example.com's IP)

You should see:

• ARP — Your machine resolving your gateway's MAC address

• DNS — The query for example.com and the response

• TCP SYN → SYN-ACK → ACK — The three-way handshake

• HTTP GET — Your browser's request

• HTTP 200 OK — The server's response with the HTML

• TCP FIN → ACK → FIN → ACK — The connection teardown

Click on any packet and look at the bottom pane — you'll see the exact encapsulation layers: Ethernet (Layer 2) → IP (Layer 3) → TCP (Layer 4) → HTTP (Layer 7). This is the encapsulation from section 8, visible and real.

25. Troubleshooting Like a Pro

Let's put everything together into a systematic method.

The Golden Rule: Work Up the OSI Model

Start from Layer 1 and work your way up. Don't jump to "maybe the DNS is broken" before confirming the cable is plugged in.

Scenario 1: "I can't connect to the internet"

# Layer 1: Is the physical connection up?
ip link show
# Look for: state UP

# Layer 2: Do I have a valid IP? (If not, DHCP failed)
ip addr show
# If you see 169.254.x.x → DHCP problem
# If you see no IP at all → interface is down

# Layer 3: Can I reach my gateway?
ip route show default                    # Find gateway IP
ping -c 3 192.168.1.1                   # Ping it

# Layer 3: Can I reach the internet by IP (bypassing DNS)?
ping -c 3 8.8.8.8

# DNS: Can I resolve names?
nslookup google.com
dig google.com

# Application: Can I reach a website?
curl -I https://google.com

Interpretation:

• Gateway ping fails → Local network issue (cable, Wi-Fi, router)

• 8.8.8.8 fails but gateway works → Router/ISP issue

• DNS fails but 8.8.8.8 works → DNS problem (change to 8.8.8.8 or 1.1.1.1)

• curl fails but DNS works → Firewall, proxy, or application-level issue

Scenario 2: "The website is slow"

# Where is the time being spent?
curl -w "\n  DNS Lookup:   %{time_namelookup}s\n  TCP Connect:  %{time_connect}s\n  TLS Handshake: %{time_appconnect}s\n  First Byte:   %{time_starttransfer}s\n  Total Time:   %{time_total}s\n" -o /dev/null -s https://slow-website.com

Interpretation:

• time_namelookup is high → Slow DNS. Try a faster resolver.

• time_connect is high → Network latency or congested path. Use mtr to find where.

• time_appconnect is high → Slow TLS handshake. Server might be overloaded.

• time_starttransfer is high → Server is slow to process your request. Not a network problem.

Scenario 3: "I can ping it but can't connect to the service"

Host is reachable (Layer 3) but the service isn't responding (Layer 4/7):

# Is the port open?
nc -zv hostname 80
nc -zv hostname 443

# Is the service actually running? (on the server)
ss -tulnp | grep :80

# Is a firewall blocking?
sudo iptables -L -v -n | grep 80
sudo ufw status

Scenario 4: "Intermittent connectivity"

The hardest type of problem. Things work sometimes and not others.

# Extended ping to measure packet loss
ping -c 100 google.com
# Look at "packet loss" in the summary

# Continuous route monitoring
mtr --report-cycles 60 google.com
# Run for 60 cycles and look for packet loss at specific hops

# Check for interface errors
ip -s link show eth0
# Look for: errors, dropped, overruns

# Check DNS consistency
for i in $(seq 1 10); do dig +short example.com; sleep 1; done
# Watch for inconsistent results

26. Building Your Home Lab

The best way to learn networking is hands-on. Here's how to set up a lab.

Option 1: Virtual Lab (Free)

Use VirtualBox or KVM to create virtual machines:

1. Install VirtualBox (free) or use KVM/QEMU on Linux

2. Create 2-3 Ubuntu Server VMs

3. Configure network types:

   • NAT — VM accesses internet through host

   • Internal Network — VMs only talk to each other (perfect for isolated experiments)

   • Bridged — VM gets its own IP on your home network

4. Practice: SSH between VMs, set up a web server, configure iptables, run Wireshark

Option 2: Raspberry Pi Lab

• Pi-hole — Network-wide ad blocker that teaches DNS

• Nginx web server — Learn HTTP, TLS, and reverse proxying

• WireGuard VPN — Access your home network remotely

• Prometheus + Grafana — Network monitoring and visualization

Option 3: Docker Networking

# Create an isolated network
docker network create --subnet=172.20.0.0/16 mylab

# Run containers on it
docker run -d --name web --network mylab --ip 172.20.0.10 nginx
docker run -d --name client --network mylab alpine sleep 3600

# Test connectivity between containers
docker exec client ping web
docker exec client wget -qO- http://web

# Inspect the network
docker network inspect mylab

Concrete Projects (Ordered by Difficulty)

1. Set up SSH between two machines with key-based authentication

2. Run a web server (nginx) and access it from another device

3. Deploy Pi-hole and analyze the DNS queries your devices make

4. Write iptables rules that only allow SSH and HTTP to your server

5. Capture a full HTTP transaction with tcpdump and analyze it in Wireshark

6. Configure nginx as a reverse proxy with HTTPS (Let's Encrypt)

7. Set up WireGuard VPN and connect to your home network remotely

8. Build a two-subnet network in VirtualBox with a router VM connecting them

9. Set up a local DNS server with bind9 or dnsmasq and use it for your network

10. Deploy a monitoring stack (Prometheus + Grafana + node_exporter) and build dashboards

27. Glossary

28. Resources and Next Steps

Free Learning Resources

Fundamentals: Professor Messer's CompTIA Network+ videos (YouTube), Cloudflare Learning Center, The TCP/IP Guide (online)

Hands-on: TryHackMe (guided labs), Hack The Box (more advanced), OverTheWire Bandit (command-line challenges)

Deep dives: "Computer Networking: A Top-Down Approach" by Kurose & Ross, "TCP/IP Illustrated" by W. Richard Stevens, Beej's Guide to Network Programming

Certifications

• CompTIA Network+ — Standard entry-level networking certification

• Cisco CCNA — Vendor-specific but highly respected, deep routing and switching

• AWS/Azure/GCP Cloud Networking — Cloud-specific network certifications

What to Explore Next

Once you've mastered this guide: VLANs, load balancing, SDN (Software-Defined Networking), network automation (Ansible/Terraform), container networking (CNI, service mesh), eBPF for observability, Zero Trust architecture, and IPv6 deployment.

Wrapping Up

If you've read this far, you now have a genuine foundation in networking — not just the theory, but the practical commands, the mental models, and the troubleshooting methodology. You understand how data travels from your keyboard to a server across the world and back. You know how to systematically debug when things break.

The most important thing now is to practice. Open a terminal and run those commands. Set up a home lab. Break things on purpose and fix them. Capture packets with Wireshark and stare at them until the layers make sense.

Networking is one of those skills that compounds. Every new concept connects to things you already know. Subnetting clicks once you understand binary IP addresses. Firewalls make sense once you understand ports. Troubleshooting becomes systematic once you internalize the layer model.

Every expert was once a beginner who felt overwhelmed by ping. You've got this.

Found this helpful? Share it with someone starting their networking journey. Spot an error? I'd love to hear about it — the best technical content is always a collaboration.