TCP vs UDP Explained

A socket is the 4-tuple (or 5-tuple with protocol): local IP, local port, remote IP, remote port, plus TCP vs UDP. Well-known destinations (22, 53, 80, 443) are how clients find a service. The client almost always picks an ephemeral high source port so it can open many connections at once. When a firewall log says 10.0.2.15:49152 → 93.184.216.34:443 tcp, the 443 is "web"; the 49152 is "this laptop's temporary door." Listening is not the same as connected. A LISTEN socket is a door waiting. ESTABLISHED (TCP) is a conversation in progress. UDP often shows UNCONN / no ESTABLISHED because there is no connection object in the TCP sense — only recent datagrams if the stack tracks them. If you do not separate those states, you will report "SSH is connected" when you only saw sshd listening.

TCP is connection-oriented. Before useful data, client and server agree they both exist and share starting sequence numbers. The classroom picture is three steps: (1) Client sends SYN ("I want to talk, here is my sequence start"). (2) Server replies SYN-ACK ("I heard you; here is mine"). (3) Client sends ACK. After that, both sides send a byte stream with sequence numbers, acknowledgements, and retransmissions if a segment goes missing. FIN/RST tear the session down. You do not need a raw-packet tool to use that picture in a SOC ticket. Reliability is the product: ordered bytes, loss recovery, flow control so a fast sender does not drown a slow receiver. The cost is latency (the handshake RTT), state on both ends, and head-of-line blocking when a lost segment stalls the stream. HTTP, HTTPS, SSH, SMTP, IMAP — the protocols you just studied — almost always ride TCP because a missing byte is a broken page, a truncated key exchange, or a chopped mail command.

Failure modes follow the state machine. SYN sent, no SYN-ACK: filtered or dead listener (or you probed an IP you should not have — don't). SYN-ACK then RST: the door slammed. Lots of SYNs, few ACKs: a flood, a scan, or a misconfigured client. A stateful firewall can allow ESTABLISHED,RELATED after seeing a good handshake, and drop stray ACK/data that never SYNed. That is a feature. It is also why "the ping works but the website does not" is not a paradox: ICMP is not TCP/443.

UDP is connectionless. The application writes a datagram; the stack sends it. No three-way handshake, no automatic retransmission, no ordering guarantee. DNS queries are the everyday example: a small question, a small answer, UDP/53, often done in one round trip. If the answer is huge, DNS may retry over TCP — the exception that proves the rule. Live video, VoIP, and games prefer UDP (or UDP-based QUIC) because a late packet is worse than a missing one; they would rather skip a frame than stall the stream for TCP recovery. Security teams also know UDP as an amplifier's friend: a tiny spoofed query, a large response aimed at a victim. You will not run that. You will remember that "UDP is faster" is not the same as "UDP is harmless." On a host firewall, UDP is awkward because there is no ESTABLISHED handshake to hang state on. Devices track "we saw a recent outbound datagram to that IP:port, so inbound replies may return for a few seconds." Timeouts, direction, and asymmetric routing make UDP policy harder than TCP policy. Blocking UDP/53 "to be safe" looks like the internet died even though TCP/443 still works — you already met that with ping vs curl.

ss talks to your kernel. -t TCP, -u UDP, -l listening, -n numeric ports (skip extra DNS). This is inventory of your machine, the same ethic as Topic 2. You will later map numbers to services; today, label each line: protocol, port, bind address, and whether TCP would have a handshake if a client connected locally.

ss -tuln

ss -tln          # TCP listen
ss -uln          # UDP listen

mkdir -p "$HOME/cyberlium-lab"
{
  echo '=== ss -tuln ==='
  ss -tuln
  echo
  echo 'Pick 2 lines: protocol, port, bind (127.0.0.1 vs 0.0.0.0/*)'
  echo 'TCP listeners would 3-way handshake on connect; UDP would not.'
} > "$HOME/cyberlium-lab/tcp-udp-ss.txt"
chmod 600 "$HOME/cyberlium-lab/tcp-udp-ss.txt"

You can treat ports as multiplexed doors, tell the TCP handshake as SYN / SYN-ACK / ACK without building a packet tool, and explain why DNS and video accept UDP's trade while SSH and HTTP generally cannot. Stateful firewalls hang TCP on a handshake; UDP gets a shorter, leakier memory. Next — Common Ports You Must Know — why 22, 53, 80, 443 and a short list of others are the numbers that show up in every triage, still interpreted with 127.0.0.1 vs 0.0.0.0.