TCP vs UDP

Think about two everyday things you do online:

  • You’re on a video call, and suddenly someone’s face freezes for half a second, then jumps ahead to catch up. A little glitch, but the call keeps going.
  • You download a file, and somehow it’s never broken. It’s either fully there and works, or it failed and you try again. It’s never half-correct.

So why is one of them okay with a tiny glitch, while the other one has to be perfect every single time? That’s not an accident. Those two things are using different rules to move data, and they were built for very different needs. Those rules have names: TCP and UDP. By the end of this lesson, you’ll know exactly what each one does and when you’d pick it.

🎯 Why Two Protocols

First, let’s get the word “protocol” out of the way:

  • A protocol is just an agreed set of rules for how two computers talk to each other. Both sides follow the same rules, so they understand one another.
  • TCP and UDP are both protocols that carry your data across the network. They both chop your data into small chunks called packets and send them across.
  • A packet is just a small piece of your data with an address on it, kind of like a single envelope in the mail.

So if they both do the same basic job, why have two? Because they make different trade-offs:

  • TCP cares about getting everything right. It checks that every packet arrived, in the correct order, and asks again for anything that got lost.
  • UDP cares about speed. It just throws the packets out and moves on, without stopping to check.
  • One is careful and a bit slower. The other is fast but a bit careless. Neither is “better”, they’re built for different jobs, and that’s the whole point of this lesson.

📮 A Real-World Analogy

Imagine you need to send a letter to your friend Alex. You’ve got two ways to do it.

The first way is registered post:

  • You hand over the letter, and the post office tracks it the whole way.
  • When Alex receives it, you get a delivery confirmation back saying “yes, it arrived”.
  • If it gets lost on the way, the system notices and the letter gets sent again.
  • It’s reliable, you know it got there, but all that checking takes a little extra time. That’s TCP.

The second way is dropping a stack of postcards in a public mailbox:

  • You write a bunch of postcards and just drop them in. Fast and cheap.
  • No tracking, no confirmation. Most will reach Alex, but one or two might get lost, and you’ll never know which.
  • You don’t wait around or resend anything. You’ve already moved on. That’s UDP.

Keep these two in your head. Registered post versus a pile of postcards. Every difference below maps back to this.

🔒 What is TCP

Let’s start with the careful one.

  • TCP stands for Transmission Control Protocol. Its whole job is to make sure your data arrives complete and in the right order.
  • It’s called connection-based, which means before any real data moves, the two computers first set up a proper connection and agree to talk. Like dialing someone and waiting for them to pick up before you start speaking.
  • That setup is done with a little greeting called the three-way handshake. It’s three quick messages that open the connection.

Here’s how that handshake goes:

  • Your computer says SYN, which basically means “hi, can we talk?” (SYN is short for synchronize.)
  • The server replies SYN-ACK, meaning “yes, let’s talk, and I heard you.” (ACK is short for acknowledge.)
  • Your computer says ACK back, meaning “great, I heard you too.” Now the connection is open.

Client: SYN

Server: SYN-ACK

Client: ACK

Connection open

Once that line is open, TCP keeps doing careful work for every chunk of data:

  • It numbers the packets, so the other side can put them back in the correct order even if they show up jumbled.
  • For each packet that arrives, the receiver sends back an acknowledgement, a tiny “got it” message.
  • If a packet goes missing and no “got it” comes back, TCP notices and resends that packet. Nothing gets silently dropped.

Send packet 1

Got it (ack)

Send packet 2

Lost, no ack

Resend packet 2

Got it, now in order

All that ordering, acknowledging, and resending is great for accuracy. But it does add some overhead, which just means extra back-and-forth work that takes a bit of time. That’s the price TCP pays for being reliable.

⚡ What is UDP

Now the fast one.

  • UDP stands for User Datagram Protocol. Its whole job is to move data as fast as possible with as little fuss as possible.
  • It’s connectionless, which means there’s no handshake first. No dialing, no waiting for a pickup. Your computer just starts sending right away.
  • A “datagram” is UDP’s word for one of those small packets it fires off.

Here’s what UDP does and, more importantly, what it doesn’t do:

  • No ordering. Packets can arrive in any order, and UDP won’t fix that for you.
  • No delivery guarantee. If a packet gets lost on the way, UDP doesn’t notice and doesn’t care.
  • No resending. A lost packet stays lost. There’s no “got it” message and nothing gets sent again.

Send packet 1

Send packet 2

Send packet 3

Lost, ignored

Keep sending

So why would anyone want that? Because skipping all the checking makes it very fast and very light:

  • There’s almost no overhead, so packets reach the other side with very little delay. That low delay is called low latency.
  • For things happening live, like a voice call, getting the data there now matters more than getting every last packet. An old packet that arrives late is useless anyway.
  • It’s the “drop the postcards and move on” approach. Most arrive, and that’s good enough for the job.

⚖️ TCP vs UDP

Here’s the side-by-side, so you can see the trade-offs at a glance.

Feature TCP UDP
Reliable? Yes, resends lost data No, lost data stays lost
Ordered? Yes, packets arrive in order No, any order
Speed Slower, more overhead Faster, low overhead
Connection Connection-based (handshake first) Connectionless (just send)
Best for Web, email, file transfer Video, voice, gaming, DNS

The short version: TCP trades a little speed for accuracy, and UDP trades accuracy for speed.

🧩 When to Use Each

Now the question that actually matters in real life: which one do you pick? It comes down to one question, does accuracy matter more, or does speed?

Reach for TCP when every byte has to be correct:

  • Loading web pages. A page with missing pieces is broken, so the web mostly runs on TCP.
  • Email. You don’t want half a message showing up.
  • File transfer and downloads. A file that’s even slightly wrong is useless, so it must arrive complete and in order.
  • Basically anything where “correct” beats “fast”.

Reach for UDP when speed matters more than perfection:

  • Live video and voice calls. A dropped packet just means a tiny glitch, and waiting to resend it would make the call lag, which is worse.
  • Online gaming. Player positions update constantly, so a lost update doesn’t matter, the next one fixes it. Late data is useless data here.
  • DNS lookups, the quick “what’s this website’s address?” requests. They’re tiny and fast, so UDP fits perfectly.
  • Anything live, where an old resent packet would arrive too late to be useful anyway.

The one-line rule

If your data must be complete and correct, pick TCP. If your data is live and a little loss is okay as long as it’s fast, pick UDP. That single question answers most cases.

⚠️ Common Mistakes and Misconceptions

A few things trip people up here, so let’s clear them out:

  • “UDP is just a worse version of TCP.” No. UDP isn’t broken TCP. It’s a deliberate design that drops the checking on purpose to gain speed. For live data, that’s exactly what you want.
  • “TCP is always the right choice because it’s reliable.” Not true. For a live video call, TCP’s resending would actually cause lag and stutter, because it keeps waiting on old packets. Reliable isn’t always better.
  • “UDP loses tons of data, so it’s unsafe to use.” It usually doesn’t. On a healthy network, most UDP packets arrive just fine. It just doesn’t promise to fix the rare one that gets lost, and for streaming or gaming that’s totally fine.
  • “Connectionless means UDP doesn’t really connect at all.” It still sends data between two machines. It just skips the handshake setup, so there’s no formal connection to open or close first.

🧩 What You’ve Learned

You can now explain the difference between the two main ways data moves across a network. Here’s what you’ve picked up.

  • ✅ TCP and UDP are both protocols that carry data as packets, but they make opposite trade-offs.
  • ✅ TCP is reliable, ordered, and connection-based. It uses the three-way handshake and resends lost packets, with a bit more overhead.
  • ✅ UDP is connectionless and fast. It has no ordering, no delivery guarantee, and no resending, but very low overhead.
  • ✅ Use TCP when accuracy matters: web, email, file transfer.
  • ✅ Use UDP when speed matters: live video, voice, gaming, DNS.
  • ✅ Neither is “better”. The right choice depends on whether you need correct data or fast data.

Check Your Knowledge

Test what you learned. Pick an answer for each question, then click Check.

  1. 1

    What is the main difference between TCP and UDP?

    Why: TCP confirms delivery and keeps packets in order at the cost of overhead, while UDP just sends fast with no guarantees.

  2. 2

    What is the three-way handshake?

    Why: The three-way handshake is how TCP opens a connection before sending data, using the SYN, SYN-ACK, and ACK messages.

  3. 3

    Why would you choose UDP for a live voice call?

    Why: For live data, getting it there now matters more than getting every packet, so UDP's speed beats TCP's resending, which would only cause lag.

  4. 4

    Does UDP guarantee that packets arrive in order?

    Why: UDP gives no ordering or delivery guarantee; if an app needs ordering with UDP, the app itself has to handle it.

🚀 What’s Next?

Now that you know how data actually moves, you can go up a level and see where these protocols fit in the bigger picture.

  • How the Internet Works shows how all these pieces connect into the network you use every day.
  • WebSockets builds on TCP to keep a live, two-way connection open between your browser and a server.

Get these down, and you’ll have a solid grip on the network fundamentals every backend and system design interview leans on.

Share & Connect