TCP vs UDP

📦 The Postal System Analogy

Think of it like two different ways to send something to a friend.

TCP (Transmission Control Protocol) is like sending a package via registered post with tracking. You get a delivery confirmation, it arrives in order (page 1 before page 2), and if it gets lost in transit, the post office re-sends it. Reliable, but all that tracking adds time and effort.

UDP (User Datagram Protocol) is like throwing paper airplanes with messages across the room. Super fast, no waiting for confirmation, but some might land behind the couch and never be found. No guarantees — but it's instant.

Both are "transport protocols" — they define HOW data travels between two computers. They sit beneath HTTP (which you use for websites) and above the raw internet wires.

💡 Simple Summary: TCP = guaranteed delivery, but slower (registered mail with tracking). UDP = fast delivery, but some data might get lost (paper airplane). Choose based on what matters more: accuracy or speed.

💬 TCP: Every Message MUST Arrive (Like WhatsApp)

When you send a WhatsApp message to your friend, can you accept "oops, 3 of your 10 messages disappeared"? Of course not! Every single message must arrive, and in the correct order.

That's TCP. It guarantees:

The cost? All these guarantees take time. Confirmations, re-sends, ordering — it's extra work that adds latency (delay).

🎥 UDP: Speed Over Perfection (Like a Video Call)

Now imagine you're on a Zoom video call. Your friend's face freezes for a split second then continues smoothly. What happened?

A few UDP packets (tiny pieces of video data) got lost. But here's the thing — by the time you could re-send those lost frames, 10 NEW frames have already arrived. The lost frame is old news! So UDP just... skips it and moves on.

Would you rather:

For real-time stuff, a dropped packet is less annoying than a delayed one. That's why UDP exists.

💡 Simple Summary: TCP is like WhatsApp messages — every single one must arrive perfectly. UDP is like a live video call — a dropped frame is OK, but freezing is NOT.

🤝 The 3-Way Handshake: How TCP Starts a Conversation

Before TCP sends ANY data, the two computers introduce themselves. It's like starting a phone call:

Step 1 — "Hey, can you hear me?" (SYN)

Your computer sends a message: "Hey server, I want to talk to you."

Step 2 — "Yes! Can you hear ME?" (SYN-ACK)

The server responds: "Yep, I hear you! Can you hear my response?"

Step 3 — "Loud and clear, let's go!" (ACK)

Your computer confirms: "Perfect, I got your response. Let's start sending real data."

Only AFTER these 3 steps does actual data start flowing. This handshake takes about 1 round-trip of time (if the server is 70ms away, that's 70ms before any data moves).

UDP? No handshake. Just start throwing data immediately. That's why UDP is faster to begin.

❓ But wait — if UDP doesn't do a handshake, how does the server even know you're there?

It doesn't, really! UDP is "fire and forget." The server just listens for incoming packets from anyone. There's no formal connection, no confirmation. This makes UDP simpler and lighter — the server doesn't need to track who's connected. But it also means the server can't guarantee you received anything.

💡 Simple Summary: TCP shakes hands before talking (polite but slow). UDP just starts shouting (rude but fast).

📋 When to Use TCP vs UDP

Use TCP when data MUST be perfect:

Use UDP when SPEED matters more than perfection:

Why not ALWAYS use TCP?

TCP has overhead — the handshake, the confirmations, the re-sending, the ordering. For every 1 byte of real data, TCP might send 2 bytes of "management" data. When you're streaming video at 30 frames per second, you can't afford to wait for a re-send of frame #47 when you're already on frame #55.

Also, TCP has a problem called head-of-line blocking: if packet #3 is lost, packets #4, #5, and #6 all WAIT in line until #3 is re-sent. The whole thing stalls because of one lost packet. For real-time apps, that stall is unacceptable.

💡 Simple Summary: TCP for things that must be correct (banking, messages, files). UDP for things that must be fast (video, gaming, live streaming). Many apps use BOTH — games send player positions via UDP but chat messages via TCP.

🎯 Key Points for Interviews

❌ Common Mistakes in Interviews

Mistake 1: Saying "UDP is bad" — UDP isn't bad, it's DESIGNED for speed. Netflix uses UDP for video because reliability is handled at the app level. It's a feature, not a bug.

Mistake 2: Forgetting TCP's handshake cost — It adds a full round-trip before ANY data moves. For short one-time queries (like DNS), that's too expensive. That's why DNS uses UDP.

Mistake 3: Not mentioning head-of-line blocking — This is TCP's main limitation and the reason HTTP/3 was created. One lost packet blocking ALL streams is a huge problem.

Mistake 4: Saying "gaming uses only UDP" — Only real-time position data uses UDP. Chat, inventory, match results, leaderboards — those use TCP. Most games use BOTH protocols.

Mistake 5: Not connecting to HTTP/3 and QUIC — Modern interviewers expect you to know that HTTP/3 runs over QUIC (UDP-based) to solve TCP's head-of-line blocking while keeping reliability.

🎯 Interview One-Liner

"TCP guarantees reliable, ordered delivery via handshakes and acknowledgments — ideal for data integrity. UDP sacrifices guarantees for speed and low latency — ideal for real-time apps. HTTP/3's QUIC protocol combines UDP's speed with selective reliability to solve TCP's head-of-line blocking."

Interview Q&A