How the internet works

To secure networks and web apps, you first need to understand how the internet works — how data travels from your device to a server and back. You can't protect what you don't understand. This lesson builds the mental model everything else in the course rests on: packets, addresses, the client-server model, and where security fits. Let's see how data moves. Let's build the foundation.

The journey of a request

WHAT HAPPENS WHEN YOU VISIT A WEBSITE (the client-server model):

1. YOUR DEVICE (the CLIENT) wants a page from a SERVER (a computer hosting the
   site somewhere).
2. It needs the server's ADDRESS. You type a domain (example.com); DNS (the
   internet's phonebook — next lesson) translates it to an IP ADDRESS
   (like 93.184.216.34).
3. Your device sends a REQUEST across the internet to that IP. The data is
   broken into small PACKETS, each labelled with source + destination
   addresses.
4. Packets travel through many ROUTERS (devices that forward packets toward
   their destination), hopping across networks — your Wi-Fi -> your ISP ->
   the wider internet -> the server's network.
5. The SERVER receives the request, processes it, and sends back a RESPONSE
   (the web page), again as packets.
6. Your device REASSEMBLES the packets into the page.

KEY IDEAS:
- The internet is a network OF networks; data hops across MANY devices you
  don't control to reach its destination.
- Data is sent in PACKETS (not one stream), each independently routed.
- CLIENT (asks) <-> SERVER (responds) is the core model of the web.

When you visit a website, the client-server model kicks in: your device (the client) wants a page from a server (a computer hosting the site). It needs the server's address, so DNS (the internet's "phonebook" — next lesson) translates the domain (example.com) into an IP address (like 93.184.216.34). Your device sends a request across the internet, broken into small packets (each labelled with source and destination addresses), which travel through many routers (forwarding them toward the destination) — hopping across networks (your Wi-Fi → your ISP → the wider internet → the server). The server processes the request and sends a response (the page), again as packets, which your device reassembles. The key ideas: the internet is a network of networks where data hops across many devices you don't control; data travels in independently-routed packets; and client (asks) ↔ server (responds) is the core model of the web.

Where security fits into the picture

WHY UNDERSTANDING THIS MATTERS FOR SECURITY — each part is a place attacks +
defences happen:

- DATA IN TRANSIT — packets travel across networks + devices you don't
  control (routers, ISPs, Wi-Fi). Anyone in the PATH could potentially see or
  tamper with UNENCRYPTED data. -> ENCRYPTION (HTTPS/TLS) protects it in
  transit (later lessons). This is why the padlock matters.

- THE NETWORK LAYER — attacks like sniffing, man-in-the-middle, spoofing, and
  denial-of-service target how data MOVES (this course's network lessons).

- THE SERVER + WEB APP — the server processes your requests; if the app is
  insecure, attackers send MALICIOUS requests to exploit it (the OWASP/web
  lessons — injection, XSS, etc.). Most web attacks are crafted REQUESTS.

- DNS — if DNS is poisoned/spoofed, you could be sent to a FAKE server.

- ENDPOINTS — your device + the server are targets too (malware, etc.).

THE MODEL FOR THIS COURSE:
- NETWORK SECURITY — protecting data + systems as data moves across networks
  (packets, protocols, the infrastructure).
- WEB SECURITY — protecting web APPLICATIONS from malicious requests +
  exploited vulnerabilities.
Both matter; this course covers both, always to DEFEND.

Understanding this matters for security because each part is where attacks and defences happen. Data in transit — packets cross networks and devices you don't control, so anyone in the path could see or tamper with unencrypted data → encryption (HTTPS/TLS) protects it (later lessons; this is why the padlock matters). The network layer — attacks like sniffing, man-in-the-middle, spoofing, and denial-of-service target how data moves. The server + web app — if the app is insecure, attackers send malicious requests to exploit it (the OWASP/web lessons — injection, XSS; most web attacks are crafted requests). DNS — if poisoned, you could be sent to a fake server. And endpoints — your device and the server are targets too. This gives the model for the course: network security (protecting data and systems as data moves — packets, protocols, infrastructure) and web security (protecting web applications from malicious requests and exploited vulnerabilities). Both matter; this course covers both — always to defend.

The mistake beginners make

The foundational mistake is trying to secure systems without understanding how they work — jumping to tools and fixes without grasping packets, requests, and the client-server model, so security stays mysterious and you can't reason about where attacks happen or why defences work. Understand the fundamentals first — you can't protect what you don't understand. The second mistake is assuming data in transit is private by default — not realising that unencrypted data travels across many devices you don't control (routers, ISPs, Wi-Fi), where it can be read or tampered with, so anything sent over plain HTTP is exposed. Understand why encryption (HTTPS) is essential. The third mistake is thinking security is only about the "server" or only about the "network" — focusing on one layer while ignoring the other, when both the network (how data moves) and the web app (how requests are handled) are attack surfaces. Secure both layers (defence in depth). Understand how the internet actually works, know that in-transit data is exposed without encryption, and secure both the network and the application layers.

Your turn

---

Your turn

1. Trace a request: describe (in your own words) what happens when you visit a website — client asks, DNS resolves the domain to an IP, the request travels as packets through routers to the server, the server responds, your device reassembles the page.
2. Identify the attack surfaces: for that journey, name where attacks/defences happen — data in transit (needs encryption), the network layer (sniffing/MITM/DoS), the web app (malicious requests), DNS (spoofing), and the endpoints.
3. Understand 'in transit' exposure: recognise that unencrypted data crosses many devices you don't control, so anyone in the path could read/tamper with it — which is why HTTPS/TLS matters.
4. See both halves of the course: distinguish network security (protecting data as it MOVES) from web security (protecting the APPLICATION from malicious requests) — you'll cover both.
5. Adopt the mindset: commit to understanding how things work before securing them (you can't protect what you don't understand) and to defending both the network and the application layers.

Key points

• The internet uses the client-server model: your device (client) requests a page from a server; DNS translates the domain to an IP address; the request travels as PACKETS through many ROUTERS across networks; the server responds; your device reassembles the page.
• Key ideas: the internet is a network of networks (data hops across many devices you don't control), data travels in independently-routed packets, and client (asks) <-> server (responds) is the core model.
• Security fits at each part: data in transit is exposed on untrusted networks unless ENCRYPTED (HTTPS/TLS — why the padlock matters); the network layer faces sniffing/MITM/spoofing/DoS; the web app faces malicious crafted requests (OWASP — injection/XSS); DNS can be spoofed; endpoints are targets.
• The course covers NETWORK security (protecting data + systems as data moves — packets/protocols/infrastructure) and WEB security (protecting applications from malicious requests + exploited vulnerabilities) — both, always to defend.
• The mistakes: securing systems without understanding how they work (you can't protect what you don't understand), assuming in-transit data is private by default (unencrypted data is exposed across untrusted devices), and focusing on only the network OR only the app (secure both layers).