fogserv.cloud fogserv.cloud

TCP/IP Fundamentals - How the Internet Works

Status: Active
Last Updated: 2026-08-14
Category: Networking - Phase 1: Network Fundamentals
Prerequisites: None
Time: 3-4 hours
Tags: networking, tcp-ip, osi-model, ipv4, ipv6, routing, fundamentals

Summary

The foundation of everything in this KB: how data actually moves between machines. Covers the OSI and TCP/IP models layer by layer, the difference between TCP and UDP, IPv4 and IPv6 addressing at a conceptual level, and what routers, switches, and default gateways do. Every later lesson — DNS, firewalls, Traefik, VPNs — assumes this mental model.

🎯 What You'll Learn

By the end of this guide, you'll understand:

Prerequisites: None — this is the starting point
Time Investment: 3-4 hours to read, weeks to internalize through practice
Recommended Setup: Any Linux machine (VM, WSL, or physical) to run the commands alongside

Table of Contents

  1. Why This Matters
  2. The OSI Model
  3. The TCP/IP Model
  4. Anatomy of a Packet
  5. TCP vs UDP
  6. IP Addressing (IPv4)
  7. IPv6 in Five Minutes
  8. Switches, Routers, and Default Gateways
  9. Routing Tables
  10. What Happens When You Ping
  11. Hands-On Exploration
  12. Common Gotchas
  13. Next Steps

Why This Matters

You could run docker compose up and copy firewall rules from forums without understanding any of this. It works until it doesn't — then you're stuck staring at "connection refused" with no mental model of where along the path things broke.

Networking problems are layered problems. A website can fail because:

Layer Failure Symptom
Physical Unplugged cable / bad Wi-Fi No link light, no IP
Network Wrong IP or route Ping fails: "Destination host unreachable"
Transport Firewall drops the port Ping works, connection times out
Application Service crashed Connection succeeds, HTTP 500

Without the layered model, all failures look identical. With it, each symptom tells you which layer to investigate. That's the entire value of this lesson: turning "the network is down" into "TCP port 5432 is filtered between these two hosts."

Packets don't lie. Applications lie, logs lie, users lie — but the packets on the wire tell you exactly what happened.

The OSI Model

The OSI model (Open Systems Interconnection) divides network communication into 7 layers. Nobody runs the actual OSI protocol suite anymore, but the model survives because it gives everyone a shared vocabulary.

7. Application   ── HTTP, SSH, DNS queries     "What the user sees"
6. Presentation  ── Encryption, encoding        "How data is formatted"
5. Session       ── Connections, sessions       "Who is talking"
4. Transport     ── TCP, UDP, ports            "Reliable delivery"
3. Network       ── IP, ICMP, routers          "Path between networks"
2. Data Link     ── Ethernet, Wi-Fi, MAC       "Hop to hop delivery"
1. Physical      ── Cables, radio, voltages    "Actual bits"

Mnemonic

Top-down: All People Seem To Need Data Processing.
Bottom-up: Please Do Not Throw Sausage Pizza Away.

What Each Layer Actually Does

Layer 1 — Physical: Copper, fiber, radio waves. Answers: is there electricity/light/radio making it from A to B? Failures: unplugged cables, dead switch ports, Wi-Fi out of range.

Layer 2 — Data Link: Delivers frames between devices on the same local network using MAC addresses (like aa:bb:cc:dd:ee:ff). Every network interface has a globally unique MAC burned in by the manufacturer. Switches operate here. Key insight: MAC addresses don't leave your local network — they're irrelevant past the first router.

Layer 3 — Network: Delivers packets between networks using IP addresses. Routers operate here. This is the layer where "the internet" exists — thousands of networks passing packets toward their destination.

Layer 4 — Transport: Delivers data between programs, not just machines, using port numbers, plus (with TCP) reliability: retransmission, ordering, flow control.

Layers 5–7 — Session/Presentation/Application: In practice these blur together in modern protocols. HTTP handles its own sessions; TLS sits between transport and application doing "presentation"-style work (encryption). For day-to-day work, treat layers 5–7 as "the application."

Encapsulation: How Layers Cooperate

Each layer wraps the layer above it, like envelopes inside envelopes:

Application:  [ HTTP request ]
Transport:    [ TCP header | HTTP request ]           ← segment
Network:      [ IP header | TCP header | HTTP ]       ← packet
Data Link:    [ Eth header | IP | TCP | HTTP | FCS ]  ← frame
Physical:     010110101011100100101011...             ← bits

When your browser sends an HTTP request:

  1. HTTP creates the request (L7)
  2. TCP adds source/destination ports + sequence numbers (L4)
  3. IP adds source/destination IP addresses (L3)
  4. Ethernet adds source/destination MACs + error checksum (L2)
  5. The NIC encodes it all onto the wire (L1)

At the receiving end, the process reverses — each layer strips its header and hands the payload up. This is also exactly how firewalls inspect traffic: a stateful firewall reads L3+L4 headers (IPs, ports); a DPI appliance can read up to L7.

The TCP/IP Model

The internet actually runs on a simplified 4-layer model, which maps onto OSI like this:

OSI                          TCP/IP
─────────────────────       ─────────────────────
7. Application  ┐
6. Presentation ├────────►   4. Application
5. Session      ┘
4. Transport    ─────────►   3. Transport
3. Network      ─────────►   2. Internet
2. Data Link    ┐
1. Physical     ┴────────►   1. Link (Network Access)

Both vocabularies are used interchangeably in docs, RFCs, and vendor exams. When someone says "layer 2 switch," they mean OSI L2. When they say "application-layer attack," they mean OSI L7. Learn both mappings.

Anatomy of a Packet

Here's roughly what's inside the headers you'll spend your career looking at:

IP Header (Layer 3)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         |
|         Identification        |Flags|      Fragment Offset    |
|  Time to Live |    Protocol   |         Header Checksum       |
|                       Source IP Address                       |
|                    Destination IP Address                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fields you'll actually care about:

Field What it does Why you care
Source/Destination IP Who sent it, who receives it Firewall rules match on these
TTL (Time To Live) Hop counter, decremented by every router Prevents infinite loops; traceroute abuses it
Protocol 6 = TCP, 17 = UDP, 1 = ICMP Tells the receiver which transport to hand it to

What Happens when TTL hits 0: the router drops the packet and sends back an ICMP "Time Exceeded" message. traceroute deliberately sends packets with TTL=1, 2, 3… to map every router on the path from those replies.

TCP Header (Layer 4)

Key fields:

Field What it does Why you care
Source Port Random high port (ephemeral) chosen by the client This is why your firewall sees outbound connections "from port 45123"
Destination Port The service being reached (22, 80, 443…) Port forwarding and firewall rules key on this
Sequence/Ack Numbers Track byte positions for ordering + reliability The core of TCP's reliability; also how session hijacking works
Flags SYN, ACK, FIN, RST, PSH, URG The handshake and teardown live here

The TCP Three-Way Handshake

Every TCP connection starts the same way:

Client                          Server
  │            SYN                │
  │ ────────────────────────────► │   seq=x          "I want to talk"
  │                               │
  │         SYN-ACK               │
  │ ◄──────────────────────────── │   seq=y, ack=x+1 "OK, me too"
  │                               │
  │            ACK                │
  │ ────────────────────────────► │   ack=y+1        "Confirmed"
  │                               │
  │ ══════════ DATA FLOWS ═══════ │

What Happens if the server's port is closed: it replies with a packet carrying the RST flag → your client instantly reports "Connection refused."

What Happens if a firewall silently drops the SYN: no reply at all → your client retries, waits, and eventually reports "Connection timed out."

This distinction is the single most useful troubleshooting fact in networking:

Connection refused  = host reachable, nothing listening on that port
Connection timed out = packets vanishing (firewall drop, wrong route, host down)

Teardown uses FIN (polite: "I'm done") or RST (abrupt: abort now).

TCP vs UDP

Both are Layer 4 transports sitting on top of IP. They answer the same question differently: do we need guarantees?

Property TCP UDP
Connection Yes — handshake first No — just send
Reliability Retransmits lost packets Lost is lost
Ordering Guaranteed sequence None
Speed overhead Higher (headers, ACKs, state) Minimal
Flow/congestion control Yes No
Typical latency Slightly higher Lowest possible
Used by HTTP/S, SSH, mail (SMTP), databases DNS lookups, video/voice, games, DHCP, QUIC/HTTP3

When Each One Wins

TCP wins when every byte matters: web pages, file transfers, database replication. Losing one byte corrupts the HTML or the table row, so retransmission is worth the cost.

UDP wins when now matters more than complete: live video calls. Retransmitting a video frame from 3 seconds ago is useless — better to skip it. Same for VoIP, game state, and streaming.

DNS is interesting because it uses both: UDP port 53 for normal lookups (small, fast, one query/one reply), falling back to TCP port 53 for large responses (zone transfers, DNSSEC, big answers).

# Watch the protocol choice yourself:
dig google.com              # goes over UDP :53 by default
dig +tcp google.com         # forces TCP :53

# Confirm with tcpdump while running the above:
sudo tcpdump -ni any port 53
# 14:02:01.113 eth0  Out IP 192.168.1.50.45123 > 192.168.1.1.53: UDP, length 31
# 14:02:01.131 eth0  In  IP 192.168.1.1.53 > 192.168.1.50.45123: UDP, length 47

Modern note: HTTP/3 (QUIC) runs over UDP, rebuilding TCP-like reliability in userspace to fix head-of-line blocking. So the "web = TCP" assumption is slowly changing, but TCP literacy remains essential — QUIC is designed by people who deeply understood TCP first.

IP Addressing (IPv4)

An IPv4 address is a 32-bit number, written as four octets (bytes):

192.168.1.50
= 11000000.10101000.00000001.00110010
= 3232235826 (as one integer)

Every address has two parts:

192.168.1.50
└──┬───┘└┬┘
 network  host
 part     part

Where the split happens is defined by the subnet mask (covered deeply in ip-addressing-subnets). Quick preview: 192.168.1.50/24 means the first 24 bits (192.168.1) are network, the last 8 bits (50) are the host.

Special IPv4 Addresses You Must Recognize On Sight

Address / Range Meaning
127.0.0.1 Loopback — "this machine itself" (localhost). Whole 127.0.0.0/8 is loopback
10.0.0.0/8 Private range (16.7M addresses) — big corporate networks
172.16.0.0/12 Private range (~1M addresses) — often Docker defaults, cloud VPCs
192.168.0.0/16 Private range (65k addresses) — home routers almost always use this
169.254.x.x Link-local — "DHCP failed, I made something up" — always a red flag
0.0.0.0 "All interfaces" / unspecified — common in server bind configs
255.255.255.255 Broadcast to the local segment

Private ranges are not routable on the public internet. They're reused in millions of homes and offices simultaneously. Getting from a private address to the internet requires NAT, performed by your router (covered in nat-port-forwarding).

Why Your Homelab Uses 192.168.1.x

Your router hands out addresses via DHCP:

Laptop                          Router (DHCP server)
  │ ── DHCP Discover (broadcast) ► │   "Anybody able to give me an address?"
  │ ◄── DHCP Offer ──────────────  │   "Take 192.168.1.50 for 24h"
  │ ── DHCP Request ─────────────► │   "I'd like 192.168.1.50 please"
  │ ◄── DHCP Ack ────────────────  │   "Confirmed. DNS=192.168.1.1, GW=192.168.1.1"

Along with the address, DHCP delivers three other critical settings: subnet mask, default gateway, and DNS server. When debugging "no internet," check all four — ip addr and ip route show you what was actually assigned.

IPv6 in Five Minutes

IPv4 offers ~4.3 billion addresses, which the world exhausted years ago. IPv6 uses 128 bits, giving ~340 undecillion addresses — enough to assign billions of addresses to every grain of sand on Earth.

Format

IPv4:  203.0.113.10                        (32 bits, decimal, dotted)

IPv6:  2001:0db8:0000:0000:0000:ff00:0042:8329   (128 bits, hex, colon-separated)
   →  2001:db8::ff00:42:8329                    (leading zeros dropped,
                                                 one :: replaces zero-groups)

Rules: leading zeros in a group can be dropped; the longest run of all-zero groups can be replaced with :: — but only once per address (otherwise it's ambiguous).

Structure

2001:db8:85a3:0001:8a2e:0370:7334
└────┬────┘└─┬─┘ └─────────┬──────────┘
  global    subnet     interface ID
  prefix    (your LAN) (64 bits — usually from the MAC, randomized)

Things That Change With IPv6

Check yours:

ip -6 addr show
ping -6 google.com
curl -6 https://ifconfig.co   # your public IPv6, if you have one

Homelab reality: most self-hosted stacks run happily IPv4-only behind NAT, but ignoring IPv6 entirely is one of the listed pitfalls of this course. At minimum, recognize v6 addresses in logs and know that fe80:: traffic never leaves the local link.

Switches, Routers, and Default Gateways

These words get used interchangeously by non-technical people. Precisely:

Device Layer Job Thinks in terms of
Hub L1 Repeats every bit to every port (obsolete) Nothing — pure electricity
Switch L2 Forwards frames between devices on the same LAN MAC addresses
Router L3 Forwards packets between different networks IP addresses
Gateway L3 Any device that passes traffic out of your network Usually "the router"

Your home "router" is really four devices in one box: a switch (LAN ports), a router (between LAN and ISP), a NAT engine, and often a Wi-Fi access point plus DHCP/DNS server.

How a Frame Gets Where It's Going

Say 192.168.1.50 wants to reach 203.0.113.10. Two different questions must be answered:

  1. (L3) Which next-hop should get this packet? → consult the routing table. Answer: the default gateway, 192.168.1.1.
  2. (L2) Which MAC address should the frame be addressed to? → ARP asks "who has 192.168.1.1?" The gateway answers with its MAC.

Crucial subtlety: the destination IP in the packet stays 203.0.113.10 the whole way, but the destination MAC changes at every hop. Each router strips the frame, makes its own L2 frame toward the next hop, and forwards. IPs are end-to-end; MACs are hop-by-hop.

Watch it yourself:

ip neigh show
# 192.168.1.1 dev eth0 lladdr a4:2b:b0:1c:33:d7 REACHABLE   ← your gateway's MAC
# 192.168.1.87 dev eth0 lladdr f0:9f:c2:11:04:a9 STALE      ← another LAN host

Default Gateway

The default gateway is simply the answer to "where do I send packets whose destination isn't on my own subnet?" Without it, your machine can talk to its own LAN and literally nowhere else — a classic broken-setup symptom.

Routing Tables

Every machine with an IP stack has a routing table — including your laptop. Look at yours:

ip route show
# default via 192.168.1.1 dev eth0 proto dhcp metric 100
# 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
# 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50

Reading it top to bottom, most specific match wins:

  1. 192.168.1.0/24 … via eth0 — anything addressed to my own subnet goes straight out eth0 (direct L2 delivery via ARP)
  2. 172.17.0.0/16 … dev docker0 — Docker created this; containers live here
  3. default via 192.168.1.1 — everything else goes to the gateway

That third rule is what makes the internet reachable. Notice Docker already added a route without asking you — software constantly manipulates routing tables (VPNs add routes, Kubernetes CNI plugins build whole overlay networks from them).

Adding routes manually (you'll rarely need to, but recognizing the syntax matters):

sudo ip route add 10.10.0.0/16 via 192.168.1.254 dev eth0
# "To reach 10.10.x.x, forward to 192.168.1.254 instead of the default gw"

sudo ip route del 10.10.0.0/16

Diagnostic habit: whenever connectivity fails, before touching anything else, run ip route get <destination>:

ip route get 203.0.113.10
# 203.0.113.10 via 192.168.1.1 dev eth0 src 192.168.1.50 uid 1000

It shows exactly which interface, gateway, and source IP the kernel would use — half of all "can't reach X" bugs are visible right here (wrong route, wrong source interface on multi-homed machines).

What Happens When You Ping

Let's assemble everything into one story. You type ping example.com. Here's every step:

 1. APPLICATION   ping builds an ICMP Echo Request payload
 2. DNS           "example.com" is a name — resolve it!
    ├── check /etc/hosts, systemd-resolved cache, nsswitch.conf
    ├── ask configured resolver (usually your router or 1.1.1.1) over UDP :53
    └── recursive chain eventually returns 93.184.216.34
 3. ROUTING       ip route lookup: not local → send via default gateway
 4. ARP           "who has 192.168.1.1?" → learn gateway's MAC
                  (skipped if already in the neighbor cache)
 5. ENCAPSULATION ICMP → IP header (src 192.168.1.50, dst 93.184.216.34, ttl 64)
                         → Ethernet frame (src my-mac, dst gateway-mac)
 6. PHYSICAL      NIC puts bits on the wire / radio
 7. GATEWAY       Router strips frame, decrements TTL, NAT-translates source
                  (192.168.1.50 → your public IP), forwards to ISP
 8. INTERNET      ~10-20 routers each decrement TTL and pick a next hop
                  via BGP-learned routes
 9. DESTINATION   Server receives Echo Request, swaps src/dst, replies
                  with ICMP Echo Reply
10. RETURN        Reverse path; NAT translates back to 192.168.1.50;
                  your ping prints: 64 bytes from 93.184.216.34: icmp_seq=1 ttl=56 time=14.3 ms

Every element of that story gets its own lesson in this course: step 2 is dns-fundamentals, steps 3–7 expand into ip-addressing-subnets, nat-port-forwarding, and the firewall lessons, and step 9's server side becomes reverse-proxy-introduction.

Note the ttl=56 in the output: started at 64, so roughly 8 routers were crossed (64 - 56 = 8). Free path-length information, hiding in plain sight.

Hands-On Exploration

Run these on any Linux box. Each command demonstrates a concept from this lesson:

# 1. See your own addresses (both stacks)
ip addr show
ip -brief addr          # compact version

# 2. See your routing table and confirm the default gateway
ip route show

# 3. Watch the neighbor (ARP) table fill in
ping -c1 192.168.1.1 && ip neigh show

# 4. Trace the hops to a destination (this is TTL abuse, live)
traceroute example.com
# or, if traceroute isn't installed:
mtr -rw -c 10 example.com

# 5. Observe TCP handshake vs closed port vs filtered port
nc -vz example.com 443          # succeeds → "succeeded!"
nc -vz example.com 25           # refused → RST came back
nc -w3 -vz 10.255.255.1 443     # times out → silence (simulated filter)

# 6. See the handshake with your own eyes
sudo tcpdump -ni any 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0' -c 6
# (in another terminal) curl -s https://example.com >/dev/null
# You'll see SYN → SYN-ACK → ACK, then the FIN exchange at the end.

# 7. Compare transports
dig example.com              # UDP:53
dig +tcp example.com         # TCP:53 — watch tcpdump distinguish them

# 8. Check whether you have working IPv6
ping -c3 -6 ipv6.google.com || echo "no IPv6 here"

Exercise: Before moving on, be able to answer from memory:

  1. Your machine's IP, subnet mask, gateway, and DNS server (without looking twice)
  2. Whether 10.201.55.3 would be reachable directly from 192.168.1.50 (it wouldn't — different network → needs the gateway)
  3. Why connection refused and connection timed out imply completely different failure points

Common Gotchas

Symptom Likely cause Layer First check
169.254.x.x address DHCP failed L3/L7 Router reachable? dhclient -v retry
Can ping gateway, nothing else Missing/wrong default route L3 ip route show
Ping works, TCP doesn't Firewall filtering L4 nc -vz, then firewall rules
Refused locally, works remotely Service bound to 127.0.0.1 only App/L4 ss -tlnp | grep <port>
Intermittent, slow connections Duplex mismatch / Wi-Fi interference L1/L2 ip -s link (errors counter)
Works for others, not you Duplicate IP conflict L2/L3 arping <your-ip>
Traceroute shows * * * mid-path Router deprioritizes ICMP replies L3 Often harmless — check final hop instead
Container can't reach host service Different bridge network L3 docker network inspect, ip route

Two habits worth building immediately:

  1. Always determine the layer before changing config. Random firewall edits for an L1 problem make things worse.
  2. Test inward-out: loopback → local IP → gateway → public IP → public hostname. The first failing step locates the problem.

Next Steps

You now hold the mental model every other lesson depends on. Continue in order:

  1. ip-addressing-subnets — go deep on CIDR, masks, and calculating networks by hand
  2. dns-fundamentals — the resolution system you saw in action during every ping
  3. network-troubleshooting — turn today's concepts into a debugging toolkit

🔗 Related

Choose Theme

Your selection is saved locally.

Neural Cacophony
Aperture v2
Flux v1
Mosaic Chaos
Nexus v1
Nexus Zest
Prism v2
Synapse