// networking basics — module 03

Module 3 — Networking II: Transport, Ports, and the Three-Way Handshake

Soren Brumbach · · 9 min read

Thesis: Layer 4 is where connections are actually made and where a huge amount of both scanning (red) and monitoring (blue) happens. The three-way handshake is the heartbeat of the internet — memorize it cold, because port scanning, firewalls, connection tracking, and half of what you'll ever see in a packet capture are all just the handshake, used or abused.

Prerequisite: Module 2 — Networking I: The Models, Addressing, and the Stack. You need encapsulation and IP addressing before ports and segments make sense.

3.1 Where we are in the stack

Layer 3 (IP) gets a packet to the right machine. But a machine runs dozens of programs at once — a web server, an SSH daemon, a mail server. Layer 4 (Transport) answers the next question: which program on that machine gets the data, and with what guarantees is it delivered? Two protocols do this job, and choosing between them is a fundamental design decision you'll see everywhere.

3.2 TCP vs. UDP — the two transport protocols

  • TCP (Transmission Control Protocol) — connection-oriented, reliable, ordered, error-checked. Before any data flows, the two sides establish a connection (the handshake, §3.4). Every byte is numbered, acknowledged, and retransmitted if lost, and delivered to the application in order. This costs speed and overhead, but nothing is lost or scrambled. Used by anything that must be correct: the web (HTTP/HTTPS), email (SMTP/IMAP), SSH, file transfer.

  • UDP (User Datagram Protocol) — connectionless, "fire and forget." No handshake, no connection, no acknowledgments, no ordering, no retransmission. You send a datagram and hope it arrives. This makes it fast and lightweight, at the cost of any delivery guarantee. Used where speed beats perfection or where a lost packet doesn't matter: DNS, DHCP, VoIP, video streaming, online games.

   TCP: "Are you there?" "Yes." "OK, here's the data..." [ack] [ack] [ack]
        reliable, ordered, slower — a phone call with confirmations.

   UDP: "Here's the data!" (and again) (and again)
        fast, no guarantees — postcards you drop in a mailbox.

The right mental question is always: does this application need every byte to arrive in order, or does it need speed and can it tolerate loss? That single question explains every protocol's choice. A missed frame of video is invisible; a missed byte of an SSH session would corrupt your terminal — so video is UDP and SSH is TCP.

3.3 Ports and sockets

A port is a 16-bit number (0–65535) that identifies which program on a host should receive the data. When a packet arrives at a machine, the OS reads the destination port in the Layer 4 header and hands the data to whichever program is "listening" on that port. Ports are how one IP address serves many programs at once.

A socket is the full pairing of IP address : port — it uniquely identifies one endpoint of a conversation. A complete TCP connection is identified by four things together: source IP, source port, destination IP, destination port. That 4-tuple is why your laptop can hold many simultaneous connections to the same web server — each uses a different source port.

Port numbers fall into three ranges by convention:

  • Well-known ports (0–1023) — reserved for standard services. 80 is HTTP, 443 is HTTPS, 22 is SSH. (You memorize a set of these in Module 4.)
  • Registered ports (1024–49151) — assigned to particular applications (e.g., 3306 for MySQL).
  • Ephemeral / dynamic ports (49152–65535) — temporary source ports your OS picks automatically for outgoing connections.

So when you browse a website, the connection is your random ephemeral port → the server's port 443. The server's port is fixed and predictable; yours is throwaway.

3.4 The three-way handshake — memorize this cold

Every TCP connection begins with a three-step exchange. This is the most important sequence in all of networking; you will draw it from memory, find it in captures, and recognize its abuse in scans for the rest of your career.

   CLIENT                                       SERVER
     │                                             │
     │ ──────────  SYN  (seq=x)  ─────────────────►│   "I'd like to talk.
     │                                             │    Here's my starting
     │                                             │    sequence number x."
     │                                             │
     │ ◄──────  SYN, ACK (seq=y, ack=x+1)  ────────│   "OK. I acknowledge
     │                                             │    yours. Here's mine, y."
     │                                             │
     │ ──────────  ACK (ack=y+1)  ────────────────►│   "Acknowledged.
     │                                             │    We're connected."
     │                                             │
     │ ═══════════  data now flows  ═══════════════│
  1. SYN — the client sends a segment with the SYN flag set and a random starting sequence number. "I want to start a conversation; here's where my byte-counting begins."
  2. SYN/ACK — the server replies with both SYN and ACK set: it acknowledges the client's sequence number and offers its own. "I heard you, and here's my starting number."
  3. ACK — the client acknowledges the server's number. "Confirmed." The connection is now ESTABLISHED, and data flows.

After this, sequence numbers and acknowledgment numbers track every byte in both directions. Each side tells the other "I've received everything up to byte N," and anything unacknowledged is retransmitted. That accounting is how TCP delivers on its reliability promise from §3.2 — the handshake just sets up the initial numbers.

3.5 Tearing a connection down

Connections end two ways:

  • The polite close — FIN/ACK. When a side is done, it sends a FIN ("I have no more data"). The other side acknowledges, then sends its own FIN, which is acknowledged in turn. A graceful, mutual four-step goodbye. This is why you'll see a TIME_WAIT state — the OS lingers briefly to make sure the final acknowledgments arrived.
  • The abrupt reset — RST. A RST flag says "this connection is dead — stop immediately." It's sent to reject a connection (e.g., you tried to connect to a port with nothing listening) or to tear one down forcibly. A RST is a slammed door, not a handshake.

3.6 TCP flags — the control bits

Each TCP segment carries a set of one-bit flags that control the connection. The six you must know:

  • SYN — synchronize; start a connection (step 1 & 2 of the handshake).
  • ACK — acknowledge received data; set on almost every segment after the first.
  • FIN — finish; begin a graceful close.
  • RST — reset; abort immediately.
  • PSH — push; deliver this data to the application now, don't buffer it.
  • URG — urgent; this data is high-priority (rarely used).

Why a beginner cares about flags: scanning techniques are defined by which flags they set. A normal connection uses the standard SYN → SYN/ACK → ACK dance. Scanners deliberately break that pattern to probe hosts quietly — and defenders detect scans precisely by spotting those broken patterns (§3.9). Flags are the alphabet of both.

3.7 TCP connection states

A TCP connection moves through named states, and you'll see these when you inspect live connections (ss on Linux, netstat on Windows). The ones worth recognizing:

  • LISTEN — a program is waiting for incoming connections on this port (a server, ready).
  • SYN-SENT — you sent a SYN and are waiting for the SYN/ACK (a connection being opened).
  • ESTABLISHED — the handshake completed; data can flow. The "normal, active connection" state.
  • TIME-WAIT — you closed the connection and are briefly waiting to ensure the final packets arrived. Lots of these is normal for a busy client.
  • CLOSE-WAIT — the other side closed, and you haven't finished closing your end yet.

Reading these states is a genuine skill: a pile of half-open SYN-RECV connections can signal a SYN flood (an availability attack), and a listening port you didn't expect can signal a backdoor. The state table is a live X-ray of what a machine is talking to.

3.8 UDP's model — no handshake, no state

UDP has none of the above. There is no handshake, no sequence numbers, no acknowledgments, no connection states — a UDP "conversation" is just datagrams flying independently. That simplicity is precisely why it's fast and why it behaves differently under scanning and monitoring: there's no handshake to complete or observe, so probing a UDP port is inherently ambiguous (silence might mean "open," "filtered," or "the reply got lost"). Keep this asymmetry in mind — TCP is chatty and legible; UDP is quiet and vague.

3.9 → Red/Blue

Port scanning — the foundational red-team reconnaissance step — is entirely about manipulating the handshake from §3.4:

  • A full connect scan completes the whole three-way handshake on each port. Reliable, but loud and logged.
  • A SYN ("half-open") scan sends only the SYN, reads the reply (SYN/ACK = open, RST = closed), and never sends the final ACK — leaving the connection half-formed to be stealthier.
  • FIN, Xmas, and null scans send weird flag combinations (§3.6) that a compliant TCP stack answers in predictable ways, letting an attacker fingerprint open ports and even guess the OS.

Defenders detect scans by watching for exactly these abnormal handshake patterns: many SYNs with no completing ACKs, connections to hundreds of ports from one source, RST storms. Reading the connection-state table (§3.7) is how a defender spots a suspicious session in progress. Same handshake — one side abuses its rules, the other side watches for the abuse.

Lab 3

Do these in your lab. The goal is to make the handshake and connection states real, not memorized.

  1. See what's listening. Run ss -tulnp (Linux) or netstat -ano (Windows). Identify: which programs are LISTENing, on which ports, and over TCP vs. UDP (the t and u in -tulnp). Match a port to a service you recognize.

  2. Watch a connection's states. In one terminal, run watch -n1 'ss -tan' (or repeatedly run ss -tan). In another, curl http://example.com (or connect to a service in your lab). Watch a connection appear, pass through SYN-SENT / ESTABLISHED, and settle into TIME-WAIT after closing. Name each state as it happens.

  3. Draw the handshake from memory. On paper, draw all three steps of §3.4. Label the flags set at each step (SYN; SYN+ACK; ACK) and write what each step accomplishes. Add the FIN/ACK teardown. You will verify this exact drawing against a live capture in Module 5.

  4. Reason about a scan. In words, explain the difference between a full-connect scan and a SYN scan in terms of which handshake steps each completes and why the SYN scan is stealthier. Then explain what a defender would see that gives either one away.

✅ Mastery Check — do not proceed until true

Answer out loud, without notes:

  1. Give the defining properties of TCP and of UDP, and the one question that decides which an application should use. Name two protocols that use each.
  2. What is a port, and what is a socket? What four values uniquely identify a single TCP connection?
  3. Draw the three-way handshake, naming the flag(s) at each step and what each step accomplishes. What do sequence and acknowledgment numbers do after it?
  4. What's the difference between a FIN teardown and a RST?
  5. Name the six TCP flags and why flags matter for scanning and detection.
  6. What do LISTEN, ESTABLISHED, and TIME-WAIT each mean when you see them in a connection table?
  7. Why is UDP scanning inherently more ambiguous than TCP scanning?
  8. Explain how a SYN scan abuses the handshake, and how a defender detects a scan.

And perform cold:

  • On any machine, list what's listening over TCP and UDP with one command, and identify one ESTABLISHED connection and what it's talking to.

When all of that is effortless: Module 4 — Networking III: The Protocols You'll Live In (and DNS in Depth)