How the Internet Works, TCP/IP & Ports

You're going to spend the rest of this course poking at network services. Before you poke, you need a mental picture of what actually happens when you type a URL and press Enter. Not a metaphor, the real, mechanical chain. Once you can see it, every attack surface in the rest of the course will land in a specific place along this chain.

The journey of one request

You open your browser and type https://example.com. Here's what really happens, step by step.

1. DNS, "where is example.com?"

Your computer doesn't know what example.com is. It knows IP addresses. So it asks a DNS server: what's the IP for example.com? The DNS server answers something like 93.184.216.34.

Attacker view: Whoever runs the DNS resolver (your ISP, your café, a malicious one you got tricked into using) sees every domain you look up. They can also lie, answer with the wrong IP and send you somewhere else.

2. TCP, "open a connection"

Now your computer has an IP. It opens a TCP connection to that IP on port 443 (the standard port for HTTPS). TCP is the protocol that says, "let's set up a reliable two-way pipe before sending anything." More on the handshake in a second.

Attacker view: Anyone sitting on the network path between you and the server (the café Wi-Fi, your ISP, the server's ISP) sees that you opened a connection to that IP on port 443. They don't yet know what you asked for.

3. TLS, "now make it private"

Port 443 means HTTPS, which means TLS. Your computer and the server perform a TLS handshake: they prove the server's identity using a certificate, agree on encryption keys, and from that moment on every byte they exchange is encrypted.

Attacker view: After TLS, the network attacker can still see that you're talking to that IP and roughly how much data flows. They cannot read what you're sending. (If TLS is misconfigured or the user clicks past a cert warning, that protection collapses, that's a category we'll attack later.)

4. HTTP, "GET me this page"

Inside the encrypted pipe, your browser sends an HTTP request, basically a tiny text message:

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 ...

The server reads this and decides what to do. For a static site, "send back the HTML." For a real app, "look up this user, query a database, render a page, send it back."

Attacker view: Anyone who can decrypt the TLS (the server itself, the client itself, a malicious browser extension, a compromised endpoint, a poorly configured corporate proxy) sees the full request, including cookies and any credentials you're carrying.

5. The response

The server sends back HTTP headers and a body (HTML, JSON, an image, whatever). Your browser renders it. The TCP connection may stay open for the next request or close.

Where attackers sit

Look back at those five steps. Almost every network attack in this course lives in one of those slots:

• DNS spoofing / poisoning lives at step 1.
• Port scanning, firewall evasion, raw TCP-level attacks live at step 2.
• TLS downgrade, certificate trickery, weak-crypto attacks live at step 3.
• Web app vulnerabilities (SQLi, XSS, auth bugs, IDOR) live at steps 4 and 5.

Same chain, different slot.

TCP, the three-way handshake

Step 2 mentioned a handshake. Here's what it actually is.

TCP wants a reliable connection before anyone sends real data. So it does three messages:

Client ──── SYN ────▶ Server     "Hi, I'd like to talk."
Client ◀── SYN-ACK ── Server     "Sure, I heard you. Did you hear me?"
Client ──── ACK ────▶ Server     "Yes. Let's go."

That's it. SYN, SYN-ACK, ACK. Three packets, and now both sides have a connection. Every reliable internet protocol you care about, SSH, HTTP, HTTPS, SMB, RDP, sits on top of TCP and started with that handshake.

Why you care as a tester: a tool like nmap doesn't always complete this handshake. It can send just the first SYN and watch how the server replies, that tells it whether the port is open, closed, or filtered, without ever fully connecting. That's a "SYN scan," and it's one of the most common recon moves in this whole field.

UDP, the connectionless cousin

Not everything wants a reliable, ordered pipe. Voice calls, video streams, DNS lookups, gaming, for these, "send it fast, accept some losses" beats "guarantee every byte." That's UDP.

UDP has no handshake. You just fire a packet at an IP and a port and hope it arrives. The receiver may or may not reply. There's no built-in retry, no ordering, no connection state. It's like shouting a sentence across a room: fast, simple, no guarantee anyone heard you.

You'll meet UDP most often in this course around DNS (port 53), some VPN protocols, and certain old or noisy services. Scanning UDP is famously slow and unreliable, for the same reason that shouting across a room is unreliable.

Ports, the door numbers

An IP address gets a packet to a machine. A port gets it to the right program on that machine. A server can run many services at once, a web server, an SSH server, a database, and each one listens on its own port.

Ports go from 1 to 65535. The first 1024 are "well-known" and reserved for standard services. As a beginner tester, fluency with about twenty of them carries you a long way.

Memorise the bold-print four for life: 22 SSH, 80 HTTP, 443 HTTPS, 445 SMB. You will see them every single engagement.

When you scan a target and a port comes back open, the first question is always: what service is that, and what does an attacker do with it? This table is the starting bridge.

Try it in the terminal

Open the practice terminal on the right and try:

nmap example.com

You'll get a (mocked) view of which common ports are open on a target. Notice the column with the port number, the state, and the service name, that's exactly the table above, applied to one host.

Also try:

whoami
ls
pwd

These won't do much yet, but you're going to live in this terminal for the rest of the course. Get comfortable.

Takeaway

A web request is not magic. It's: name lookup, TCP handshake, TLS handshake, HTTP message, response. Underneath those sit IP addresses, ports, and two transport protocols (reliable TCP, fire-and-forget UDP). Every attack you'll learn in this course attaches to one of those parts. From here on, when we say "attacker on the network" or "scan the host," you should be able to picture exactly what step we mean.