TCP vs UDP: When to Use What, and How TCP Relates to HTTP

I was on a video call last week when my internet decided to act up. The audio kept cutting out, but weirdly, my chat messages were arriving perfectly fine. That got me thinking — why does video break so easily while text stays reliable?

The answer lies in two protocols that run the internet: TCP and UDP. They solve the same problem differently, and understanding when to use each changed how I think about building applications.

The Phone Call vs The Loudspeaker

Here's how I explain it to friends. TCP is like a phone call. You dial someone, wait for them to pick up, say "hello," wait for them to respond, and only then start talking. If they miss something, they ask you to repeat it. It's polite, reliable, and a bit slow.

UDP is a loudspeaker announcement at a train station. The announcer doesn't check if everyone heard it. They just broadcast and move on. Some people catch it, some don't. No one's going back to repeat.

Both have their place. You wouldn't use a loudspeaker to propose to someone. But you also wouldn't call every passenger individually to announce a platform change.

When Each Protocol Wins

The rule is simple. If losing a piece of data breaks everything — use TCP. If losing a piece just means a tiny glitch — UDP is faster.

The Netflix Secret

Netflix actually uses both protocols, and this blew my mind when I first learned it.

When you open Netflix and browse movies, that's TCP. Every thumbnail, every title, every button needs to load correctly. Missing data means a broken page.

But when you hit play? The video stream often uses UDP-based protocols. Think about it — if one frame in a two-hour movie gets lost, would you rather skip that frame or pause the entire stream to retry? Netflix chooses to skip. A single dropped frame is invisible. Buffering for five seconds is annoying.

That's the trade-off. TCP guarantees delivery but adds overhead. UDP prioritizes speed but accepts some loss.

Where HTTP Fits In

This is where beginners get confused. They hear "HTTP" and think it's separate from TCP. It's not.

HTTP is an application protocol — it defines what you're asking for. "Hey server, give me this webpage." But HTTP doesn't know how to actually deliver that request across the internet. That's TCP's job.

┌─────────────────────────┐
│  HTTP (the request)     │  ← "GET /movies"
├─────────────────────────┤
│  TCP (reliable delivery)│  ← Makes sure it arrives
├─────────────────────────┤
│  IP (routing)           │  ← Finds the destination
└─────────────────────────┘

HTTP rides on TCP. They're a team. You can't send an HTTP request without TCP underneath handling the messy parts.

There's a newer version called HTTP/3 that actually uses UDP with a protocol called QUIC, but that's a rabbit hole for another day.

The Mental Model

When you're building something, ask yourself: what happens if some data doesn't arrive?

If the answer is "the whole thing breaks," use TCP. Banks use TCP. E-commerce uses TCP. You don't want your payment amount arriving as "1" instead of "100" because packets got lost.

If the answer is "eh, users won't notice," consider UDP. That's why Discord, Zoom, and multiplayer games lean heavily on UDP.

One Last Thing

Here's my favorite way to remember this:

TCP: "Did you receive my message? Please confirm. Also confirm that you confirmed."

UDP: "Message sent. Good luck out there."

Both exist for a reason. Knowing when to use each is what separates developers who build fast, reliable systems from those who wonder why their app feels sluggish or keeps breaking.

---