How the Internet Moves Data

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: The internet is not magic and it is not one thing. It is millions of computers passing small envelopes of data to each other, following a few simple rules. Attackers don’t break those rules — they use them in ways the designers didn’t expect. To defend or attack anything, you first have to see the envelopes.

Part 1: The Problem

You’re about to spend months learning to attack and defend systems. But “a system” is almost always two or more computers having a conversation: a browser talking to a server, an app talking to a database, a phone talking to an API.

If you don’t understand that conversation — what’s said, in what order, who can overhear it — then every hacking technique later will feel like memorized spells. Understand the conversation, and techniques become obvious. SQL injection, session hijacking, man-in-the-middle: every one of them is just “I listened to / changed / faked part of the conversation.”

So we start here.

Part 2: The Concept — Data Travels in Packets

When your computer sends data across the internet, it does not send it all at once. It chops the data into small chunks called packets. Each packet is like a postcard: it carries a piece of the message, plus addressing information.

Analogy — mailing a book one page at a time. Imagine you want to send a 300-page book to a friend, but the post office only accepts postcards. You’d:

1. Tear the book into 300 pages.
2. Number each page (“page 47 of 300”).
3. Write your friend’s address and your address on each.
4. Mail them all.
5. Your friend stacks them back in order using the numbers.

That’s exactly how the internet works. The “post office rules” are called protocols.

Part 3: The Two Protocols That Run Everything — TCP and IP

Together they’re called TCP/IP — the foundation of the internet.

There’s also UDP, a faster but “fire and forget” alternative to TCP — no numbering, no guarantee of delivery. It’s used for video calls and games, where speed matters more than perfection. You’ll meet it again later; for now just know it exists.

Part 4: IP Addresses and Ports

An IP address identifies a machine on a network — like 142.250.190.78. It’s the street address.

But one machine runs many programs at once (a web server, a mail server, a database…). A port identifies which program on that machine should get the packet. It’s the apartment number at that street address.

   142.250.190.78 : 443
   └────┬───────┘   └┬┘
     IP address     port
   (which machine)  (which program on it)

Some ports are conventional — programs everyone agrees on:

Why this matters for security: Every open port is a door into a machine. A core attacker activity — and a core defender activity — is finding out which doors are open. You’ll do exactly that in section 0.4.

Part 5: DNS — The Internet’s Phone Book

You type google.com, not 142.250.190.78. But computers route by IP address, not names. So something must translate the name into the number.

That’s DNS (Domain Name System). It’s a giant, distributed phone book. When you type a domain, your computer asks a DNS server, “What’s the IP for this name?” and gets a number back.

You type:  google.com
              │
              ▼
   ┌─────────────────────┐
   │  DNS server         │  "What IP is google.com?"
   │  (the phone book)   │
   └─────────┬───────────┘
             │  "It's 142.250.190.78"
             ▼
   Your browser connects to 142.250.190.78

Why this matters for security: DNS is trust you didn’t know you were giving. If an attacker can lie to you during a DNS lookup, they can send you to a fake server while the address bar still says google.com. That attack family is called DNS spoofing/poisoning. You don’t need the details yet — just register the idea: the phone book can be tampered with.

Part 6: The OSI Model — A Map, Not a Memory Test

People will tell you to memorize the OSI model — 7 layers of how networks work. Most beginners memorize it, pass a quiz, and forget it. Don’t do that. Use it as a map instead.

The idea: network communication is built in layers, each layer trusting the one below it. From bottom (physical wires) to top (the app you see):

 Layer 7  Application   ← the website, the app (HTTP lives here)
 Layer 6  Presentation  ← encryption, formatting
 Layer 5  Session       ← keeping a conversation open
 Layer 4  Transport     ← TCP / UDP (packets, reliability)
 Layer 3  Network       ← IP (addressing, routing)
 Layer 2  Data Link     ← local network hardware addresses
 Layer 1  Physical      ← actual cables, wifi, signals

The only thing you must take from this now: attacks happen at every layer. A cut cable is a Layer 1 attack. A flood of TCP packets is a Layer 4 attack. SQL injection is a Layer 7 attack. When you learn an attack later, ask “which layer?” — it makes everything click into place.

A simpler 4-layer version (the TCP/IP model) is what engineers actually use day to day: Application → Transport → Internet → Link. Either map is fine.

Part 7: Putting It Together — What Happens When You Load a Page

Here is the whole conversation, start to finish, when you visit https://example.com:

1. DNS LOOKUP
   Browser → DNS server: "IP for example.com?"
   DNS server → Browser: "93.184.216.34"

2. TCP CONNECTION (the "three-way handshake")
   Browser → Server: "SYN"        (can we talk?)
   Server  → Browser: "SYN-ACK"   (yes, can you hear me?)
   Browser → Server: "ACK"        (yes — connected)

3. TLS HANDSHAKE  (because it's HTTPS — encryption is set up)
   Both sides agree on encryption keys. Details in Phase 1.

4. HTTP REQUEST
   Browser → Server: "GET / HTTP/1.1, Host: example.com"

5. HTTP RESPONSE
   Server → Browser: "200 OK" + the HTML of the page

6. RENDER
   Browser draws the page. It may now repeat 4–5 for each
   image, script, and stylesheet the page needs.

Every single step here is something an attacker studies and a defender protects. This diagram is worth re-reading until it feels obvious.

📓 Key Terms (add these to your Master Glossary page)

🧪 Hands-On Lab

You’ll do these on your own computer, watching your own traffic. All legal, all safe.

Task 1 — Watch DNS in action Open a terminal (Command Prompt on Windows, Terminal on Mac/Linux) and run:

nslookup google.com

You’ll see one or more IP addresses. You just used the phone book directly. Try it with two more sites and notice big sites return several IPs (for load sharing).

Task 2 — Trace the route a packet takes

tracert google.com        (Windows)
traceroute google.com     (Mac / Linux)

Each line is one “hop” — one router your packet passed through on its way. You’re literally seeing the path across the internet.

Task 3 — Test if a port is open

ping google.com

ping checks whether a machine is reachable. Watch the round-trip times. (Note: some servers ignore ping on purpose — a missing reply doesn’t always mean “down.”)

Task 4 — See a real packet (optional but recommended) Install Wireshark (free, wireshark.org). Start a capture, load any website, then stop. You will see thousands of packets. Find an HTTP or DNS packet and click it open. You don’t need to understand all of it — just see that the conversation from Part 7 is real and visible.

⚠️ Common Mistakes

• Memorizing OSI layers without understanding them. The layer names are useless alone. Always tie a layer to “what attack lives here.”
• Confusing IP address and port. IP = which machine. Port = which program on it. You need both to reach a service.
• Thinking HTTPS makes you invisible. HTTPS encrypts the content of the conversation. It does not hide who you’re talking to — an observer still sees the IP and often the domain. Important nuance for later.
• Skipping the Wireshark task because it “looks scary.” It’s the single best way to make networking feel real instead of abstract.

✅ Recap & What’s Next

• The internet is computers passing small packets of data, governed by protocols like TCP and IP.
• A machine is found by its IP address; a program on it is found by its port; names are translated to addresses by DNS.
• Loading a page is a fixed sequence: DNS → TCP handshake → (TLS) → HTTP request → HTTP response.

Next (0.2): Nearly every security tool lives on Linux. We’ll get you comfortable in a Linux terminal — including why file permissions are themselves a security system.