TCP vs. UDP: The 'Registered Mail' Mental Model

Networking interviews always ask: “What’s the difference between TCP and UDP?”

The textbook answer: “TCP is reliable; UDP is unreliable.”

The Senior Engineer answer: “TCP is courteous but slow; UDP is rude but fast. And ironically, the web is moving back to UDP (HTTP/3) to fix TCP’s obsession with politeness.”

This is the Mastery Guide to Transport Protocols.

Part 1: Foundations (The Mental Model)

TCP = Registered Mail (Certified Letter)

Think of TCP (Transmission Control Protocol) as sending important legal documents via FedEx with Signature Required.

Connection Oriented: You have to call the person first to make sure they are home.
Reliable: If the truck crashes, FedEx sends another truck. You will get the letter eventually.
Ordered: Page 1 always comes before Page 2.
Heavy: All this checking takes time and paperwork.

UDP = Shouting Across a Crowded Room

Think of UDP (User Datagram Protocol) as Shouting at your friend in a bar.

Connectionless: You just start yelling. You don’t know if they are listening.
Unreliable: If someone walks between you, your friend might miss a word. You don’t repeat yourself.
Unordered: They might hear “Beer!” before “Want a?”.
Fast: Immediate. No paperwork.

Part 2: The Investigation (Debug Like a Pro)

1. The 3-Way Handshake (TCP)

Before TCP sends a single byte of data (like a webpage), it wastes time shaking hands.

SYN (Client): “Hello? Are you there?”
SYN-ACK (Server): “Yes, I am here. Are you there?”
ACK (Client): “Yes, I am here. Let’s talk.”

Cost: 1 Round Trip Time (RTT). If the server is in London and you are in Sydney, you just wasted 300ms doing nothing but saying hello.
UDP: Zero handshake. Just sends data.

2. The Packet Loss Glitch

File Download (TCP): If Packet 50 goes missing, your computer pauses the download and asks the server “Resend Packet 50!”. The whole stream stops. This is why downloads pause but never have “glitches” (corruputed data).
Video Call (UDP): If a packet with your face goes missing, UDP doesn’t care. It just shows the next frame. This is why Zoom calls include weird green artifacts or robotic audio. It’s better to show a glitchy frame now than a perfect frame 3 seconds later.

Part 3: The Diagnosis (Head-of-Line Blocking)

This is the fatal flaw of TCP that led to HTTP/3.

Imagine a single lane highway (TCP Connection). You are driving 5 cars (Web requests: HTML, CSS, JS, Image 1, Image 2).

If Car #1 (HTML) breaks down (Packet Loss):

TCP: All cars behind it MUST STOP. Even though the CSS car is perfectly fine, it cannot pass. The Highway is blocked.
Result: The webpage spins.

The Fix: HTTP/3 (QUIC) Google realized this sucks. So they built QUIC on top of UDP.

It handles reliability in the application layer, not the kernel.
It allows Car #2 to drive around a broken Car #1.
Result: UDP is the future of the reliable web.

Part 4: The Resolution (When to use What)

Don’t overthink it. Use this decision tree:

Use TCP If:

Accuracy is critical. missing a single bit destroys the file.
Examples: Web Browseing (HTTP/1, HTTP/2), File Transfers (FTP), Email (SMTP), APIs (REST/JSON).

Use UDP If:

Speed is critical. Late data is useless data.
Examples: Video Streaming (Live), VOIP (Skype/Zoom), Online Gaming (Counter-Strike positions).
Why: If I tell you “Enemy is at X:50, Y:50” and that packet is lost, it is useless to resend it 200ms later. The enemy has already moved. I need the new position, not the old one.

Final Mental Model

1
2
3
4
TCP (HTTP/REST) -> The Accountant. Slow, meticulous, guarantees every penny is counted.
UDP (Zoom/Gaming) -> The Sportscaster. Fast, loud, if you miss a word, just keep listening.

HTTP/3 (QUIC)     -> Building an Accountant on top of a Sportscaster. (Best of both worlds).

If you need every byte: TCP. If you need real-time human interaction: UDP.