2.5. TCP vs UDP

💡 First Principle: TCP and UDP both solve the problem of identifying applications (using port numbers), but they make opposite trade-offs: TCP guarantees delivery at the cost of speed; UDP maximizes speed at the cost of reliability. Think of TCP like certified mail—you get confirmation of delivery, but it takes longer. UDP is like shouting across a room—fast, but no guarantee anyone heard you.

What happens when you choose wrong: Imagine running VoIP over TCP. A packet gets lost. TCP dutifully waits, requests retransmission, and waits some more. Meanwhile, your voice call has a 500ms gap—the audio becomes unusable. Or imagine downloading a firmware image over UDP—one corrupted packet means a bricked device because there's no error recovery. Protocol choice directly impacts whether your application works.

Consider this scenario: Your video conference is choppy. Is it a TCP or UDP application? Video typically uses UDP—so the problem isn't retransmission delays. It's probably packet loss or jitter. If it were using TCP, choppiness would indicate network congestion triggering retransmissions. Knowing which protocol an application uses tells you where to look.

The exam tests whether you can match applications to protocols. When you see "real-time" or "latency-sensitive," think UDP. When you see "reliable" or "guaranteed delivery," think TCP.

Loading diagram...

Comparison:

TCP Header Structure:

Loading diagram...

The flags (SYN, ACK, FIN, RST) control the connection lifecycle—they're what makes the three-way handshake and four-way teardown work.

TCP Three-Way Handshake:

1. SYN: Client sends synchronize request
2. SYN-ACK: Server acknowledges and sends its own SYN
3. ACK: Client acknowledges server's SYN

TCP Connection Lifecycle:

Loading diagram...

Well-Known Port Associations:

⚠️ Exam Trap: DNS uses both TCP and UDP. UDP for standard queries (faster), TCP for zone transfers and responses over 512 bytes.