Blocking a Port Doesn't Block Anything
In my last post I said Phase 1 was foundations — networking, Linux, Python, basic crypto. This is the first real chunk of that: TCP, UDP, and ports. I went into it thinking I already understood this. I’ve scanned my own home network with Nmap before, I know what https:// means, I’ve SSH’d into a VM more times than I can count. Turns out knowing that a port number exists and knowing what a port number actually is are two very different things.
I got quizzed on ten scenario-based questions on this material. I got maybe four of them fully right on the first try. Not because the topic is hard — once you actually see it, it’s genuinely simple — but because I’d been carrying a few wrong assumptions for years, ones that never got tested until someone asked me to explain the mechanism instead of just naming it.
So here’s the deep version. Mistakes included, because pretending I got it right the first time would defeat the point of writing this in public.
What IP Is Actually For
IP’s entire job is to move a chunk of data from one device to another, using an addressing system — basically a postal address, but for computers. That’s it. IP does not check whether the data arrived. It does not guarantee it arrived in order. It does not resend anything if a piece goes missing along the way. It just moves things toward an address and hopes for the best.
That’s not IP being lazy — it’s a deliberate design choice. If IP had to handle addressing and reliability and ordering, every single packet on the internet would carry that overhead, including the ones that don’t want it. A live video call doesn’t want to wait around for a perfectly ordered, guaranteed-delivered stream. So the job gets split: IP handles “get this to the right device,” and the layer sitting on top of it — TCP or UDP — decides how careful to be about it.
Every Packet Is Wrapped Like a Courier Parcel
Picture packing something to send by courier. You put the actual item in a box — that’s your application data, an HTTP request, an email, whatever. You seal the box and write the receiver’s address and your own return address on the outside — that’s the IP header, source and destination IP. Then the courier company slaps its own shipping label over the whole thing, with a route code for the local hub — that’s the Ethernet header, and there’s a small sticker at the very end too, the Ethernet trailer, mostly there to check nothing got damaged in transit.
Each layer only ever reads its own label. The local delivery van doesn’t open your box, it just reads the courier company’s own label to know which hub to route it to next. That’s the whole idea behind encapsulation — every layer wraps a header (and sometimes a trailer) around whatever the layer above it handed down, and nobody but that layer ever needs to read it.
In order, outside to inside, a captured frame looks like this:
Ethernet header → IP header (source/destination IP) → TCP or UDP header (source/destination port) → the actual application data → Ethernet trailer
I actually got this wrong the first time I was asked for it out loud. I started my answer at the IP header and forgot Ethernet wraps the whole thing — header and trailer both. Called a frame “a packet” too, which isn’t even the same word. A frame is the entire wrapped parcel. A packet is what’s inside it once you peel off that outermost layer — the IP header and everything nested inside that.
TCP: The One That Double-Checks Everything
TCP is the polite one. Before it sends a single byte of real data, it runs a small handshake to confirm both sides are actually ready — like picking up a phone call and saying “hello, can you hear me,” hearing back “yes, can you hear me too,” then saying “good, go ahead.” In TCP terms that’s SYN, SYN-ACK, ACK — the three-way handshake. It’s documented in RFC 9293, the current official TCP spec — it replaced the original 1981 spec, RFC 793, back in 2022. TCP is old, but people keep patching the paperwork.
That handshake isn’t just politeness. It’s how both sides agree on starting sequence numbers, which is exactly what makes it possible to detect missing or out-of-order data later, once the real conversation starts.
Once the handshake’s done, every chunk of data gets a sequence number, and the receiver sends an acknowledgment (ACK) back for what it got. If an ACK doesn’t arrive in time, the sender resends just that missing piece — not the whole conversation. This is why TCP is called reliable: not because packets never get lost (they do, at the same actual rate as UDP), but because TCP always finds out, and fixes it.
Here’s the part I genuinely got wrong on my own quiz. I said TCP “stops the data flow” when a packet goes missing. That’s not what happens, and the real mechanism has a name: head-of-line blocking. Say packets 3, 4, and 5 get sent, but 3 is lost while 4 and 5 arrive fine. TCP won’t hand 4 and 5 over to your application yet — it holds them in a buffer and waits for 3 to be resent and arrive, so everything can be delivered to the app in order. The sender never actually stops sending anything. It’s the receiver quietly sitting on data it already has, refusing to pass it along until the gap gets filled. That’s the real reason packet loss costs TCP latency — not the resend itself, it’s everything stuck behind it in line.
UDP: The One That Doesn’t Even Look Back
UDP skips all of that. No handshake, no acknowledgment, no resending, no waiting for order. It sends, and moves on. This is defined in RFC 768 — and it’s worth knowing that RFC is from 1980, written by Jon Postel, and it’s still the only formal spec UDP has ever needed. TCP has been patched and reissued multiple times over the decades. UDP hasn’t had to change at all.
You feel this trade-off every time a video call breaks up for a second instead of freezing completely. A dropped or corrupted frame in a live call is basically worthless the moment it’s late — you can’t play a delayed video frame in the past, so there’s no point waiting to fix it the TCP way. Better to skip it, keep the call moving, and let your eyes fill the one-frame gap. That’s exactly why real-time voice, video calls, and online gaming almost always run on UDP, even though it’s technically the “less reliable” option on paper.
Ports: How One IP Address Runs a Hundred Conversations at Once
This is the part that actually confused me the most, and it’s simpler than it sounds once it clicks. Your laptop has one IP address, but it’s usually running a dozen things at once — a couple of browser tabs, a background email sync, maybe an SSH session to a server. All of that traffic goes to and from the same IP address. So how does your device know which incoming data belongs to which app?
That’s the entire reason ports exist. A port number is just a way of saying “this specific stream of data belongs to this specific app on this device.” It has nothing to do with routing across the internet, and everything to do with sorting traffic once it’s already arrived. Combine protocol + IP address + port number, and you get a socket — a full identity for one specific conversation.
A few real numbers worth actually knowing: HTTPS runs on TCP port 443, SSH on TCP port 22, DNS mostly on UDP port 53. These, and a few thousand others, are formally listed in the IANA service name and port number registry — the actual official list, not a summary of it.
One accuracy note most study material glosses over: IANA officially splits ports into three ranges, not two — System Ports (0–1023), User Ports (1024–49151), and Dynamic/Private Ports (49152–65535). A lot of exam material simplifies this down to just “well-known” (0–1023) and “ephemeral” (1024–65535), which is close enough for how most operating systems actually behave day to day, but it’s not the textbook-precise IANA breakdown if someone ever asks you the exact ranges.
Three Things I Was Sure About — Until I Was Wrong
Myth 1: “Block port 443 outbound and that app can’t reach the internet.”
Not true, and this one actually matters if you’re thinking about security at all. A port number is a convention, not a rule enforced anywhere in the protocol itself. HTTPS is usually on 443 because that’s the polite, expected thing to do — but nothing stops a developer from pointing that same traffic at port 8443, or 9999, or anywhere else in the 0–65535 range. Blocking 443 stops traffic that specifically, voluntarily chooses to use 443. It does nothing to stop the actual capability of reaching the internet. Real security has to look at what the traffic is doing, not just which door number it walked through.
Myth 2: “TCP and UDP can’t use the same port number at the same time.”
I genuinely believed this one until it got corrected — I thought if something was already “on” port 22, nothing else could touch port 22 at all. Wrong, because protocol is part of a socket’s identity. Think of TCP and UDP as two separate buildings that both happen to have an apartment numbered 22. TCP port 22 and UDP port 22 are two completely different addresses that just happen to share a number — a device can run something on each at the exact same time with zero conflict. The actual restriction is much narrower: you can’t have two different services both trying to listen on the same protocol, same port, same IP — same building, same apartment, one tenant only.
Myth 3: “TCP stops sending when a packet gets lost.”
Already covered above, but worth repeating because it’s the one I got wrong out loud, in an actual answer. It’s not that TCP stops. It’s head-of-line blocking — data that’s already arrived gets held back from the application until the missing piece catches up. The sender keeps sending the entire time.
Why Any of This Actually Matters
None of this is trivia for its own sake. Every security tool that shows up later in this roadmap sits directly on top of what’s in this post. A firewall rule that blocks by port number is only as strong as Myth 1 says it is. Something like an IDS or IPS reading a packet capture is reading exactly the headers described above — and knowing that the IP protocol field says 6 for TCP or 17 for UDP means you can read the answer directly instead of guessing from indirect clues like a missing handshake. Even a VPN tunnel is just IP packets wrapping IP packets — same rules, one layer deeper.
You can’t reason about how something gets attacked or defended if you don’t first know what it’s actually doing under normal conditions. That’s really the whole point of Phase 1.
A port number is just an address inside an address. Once that clicked, half the “advanced” networking questions stopped being scary — they were just this, applied twice.
Next up: Linux fundamentals, and probably the first real version of that port scanner.