Day 5: TCP vs UDP: How Data Is Actually Delivered

Imagine you’re moving to a new apartment.

You could hire a professional moving company they inventory every box, confirms delivery of each item, and calls you if anything goes missing. Nothing gets lost. It takes a bit longer, but everything arrives perfectly.

Or you could just throw everything in a pickup truck, drive fast, and accept that a few things might fall off. You’ll get most of it there quickly.

That’s the difference between TCP and UDP.

Both are transport protocols; they live at Layer 4 of the OSI model and govern how data moves between devices. But they make very different tradeoffs. Understanding them will change how you think about every networked application you use.

A Quick Reminder: What Are Packets?

Before we compare TCP and UDP, let’s recall something from Day 1.

Data doesn’t travel across a network as one big chunk. It gets broken into small pieces called packets. Each packet travels independently, possibly taking different routes, and gets reassembled at the destination.

TCP and UDP are the two ways those packets can be sent. They answer the question: “What rules do we follow when delivering these packets?”

TCP(Transmission Control Protocol)

TCP is the careful, reliable one. It guarantees that data arrives complete, in order, and error-free. If anything goes wrong, it fixes it.

Here’s how TCP pulls that off:

The Three-Way Handshake

Before TCP sends a single byte of real data, it establishes a connection. This happens through a three-step process called the three-way handshake:

SYN: The client sends a “synchronize” signal: “Hey server, I want to connect.”

SYN-ACK: The server replies with “synchronize-acknowledge”: “Got it. I’m ready.”

ACK: The client confirms: “Perfect. Let’s start sending data.”

Only after this handshake does real data flow; this tiny overhead is what makes TCP reliable; both sides know the connection is live before anything important is sent.

How TCP Guarantees Delivery

Once the connection is open, TCP uses several mechanisms to ensure nothing goes wrong:

Acknowledgements (ACK): Every packet that arrives safely triggers an acknowledgement back to the sender. “Packet 47 received. Send the next one.”

Retransmission: If an ACK doesn’t come back within a certain time, TCP automatically resends that packet. The sender assumes it was lost.

Sequencing: Every packet gets a sequence number. Even if packets arrive out of order (they took different routes), the receiver reassembles them in the correct sequence.

Flow Control: TCP watches how fast data is being sent and adjusts the rate so the receiver isn’t overwhelmed.

Congestion Control: If the network itself is getting overloaded, TCP slows down to avoid making it worse.

All of this happens invisibly, automatically, every time you load a webpage or send a file.

UDP (User Datagram Protocol)

UDP is the fast, no-guarantees one. It fires packets into the network and doesn’t look back.

No handshake. No acknowledgements. No retransmission. No sequencing. Just raw speed.

This sounds reckless, but for certain types of applications, it’s exactly the right choice. Here’s why.

When Losing a Packet Is Acceptable

Imagine you’re on a video call. Every second, dozens of video frames stream to your screen. If one frame gets lost in transit, what happens?

With TCP, your device would stop, request that frame again, wait for it, and then continue. By the time it arrived, it would be completely outdated, and the video would freeze awkwardly.

With UDP, your device just skips that frame and moves on to the next one. You might see a tiny glitch for a fraction of a second, but the call keeps flowing smoothly.

In real-time applications, a small amount of loss is better than delay. UDP accepts that tradeoff.

TCP vs UDP: Side by Side

Real-World Applications: Who Uses What?

Let’s make this concrete. Here’s what your favorite apps are actually using under the hood:

Uses TCP:

• Web browsing (HTTP/HTTPS): every webpage must load completely and correctly. Missing data means broken pages.
• Email (SMTP, IMAP): losing part of an email is unacceptable.
• File transfers (FTP, SFTP): A corrupted file is a useless file.
• SSH: remote terminal sessions need every keystroke to arrive perfectly.
• Database queries: wrong or missing data in a query result would be catastrophic.

Uses UDP:

• Video calls (Zoom, Google Meet): Real-time, latency is everything.
• Online gaming: A missed position update is better than a lag spike.
• Live streaming (Twitch, YouTube Live): Slight quality drops beat buffering every time.
• DNS lookups: Small, quick queries where speed matters and retrying is easy.
• VoIP (WhatsApp calls, Skype): Voice packets that arrive late are worse than lost ones.

Ports: The Other Half of the Transport Layer

We’ve talked about IP addresses, routing data to the right device. But once it arrives at your device, how does it know which application should receive it?

That’s where ports come in.

A port is a number from 0 to 65535 that identifies a specific process or service on a device. Think of it like this: your IP address is the building, and the port is the apartment number.

When data arrives at your computer, it carries both the destination IP and a destination port. The operating system reads the port number and hands the data to the correct application.

Some ports are universally standardized, called well-known ports:

So when you visit https://google.comYour browser is actually connecting to: 142.250.185.46 port 443

That port number tells the server: “This is a secure HTTPS web request, hand it to the web server process.”

QUIC: The Modern Evolution

Here’s something fascinating. The internet is evolving beyond the classic TCP vs UDP choice.

QUIC (Quick UDP Internet Connections) is a modern transport protocol developed by Google and now standardized by the IETF. It’s built on top of UDP but adds many of TCP’s reliability features built-in encryption, faster connection setup, and better handling of packet loss.

It’s what powers HTTP/3, the newest version of the web protocol. When you browse modern websites, there’s a good chance QUIC is quietly running underneath.

This is a perfect example of a theme we’ll see throughout this series: the internet doesn’t replace old technology; it builds on top of it cleverly.

Try It Yourself

You can actually see TCP connections active on your machine right now.

On Windows:

netstat -an

On Mac/Linux:

ss -tuln

You’ll see a list of active connections and listening ports, each one showing the local address, remote address, port numbers, and whether it’s TCP or UDP. Try opening a webpage first and then running the command, you’ll see the new connections appear.

A Simple Mental Model to Remember

When you can’t remember which protocol to think of, just ask:

“Does it matter if something is missing?”

• Yes → TCP. Use it for anything where every byte counts: files, web pages, emails, databases.
• No → UDP. Use it for anything where speed and real-time flow matter more than perfect voice, video, or games.

That one question covers 90% of real-world protocol decisions.

Quick Recap

TCP is connection-oriented; it does a three-way handshake, guarantees delivery, sequences packets, and retransmits anything lost. It’s slower but perfectly reliable. Use it when data integrity is non-negotiable.

UDP is connectionless. It fires packets with no setup, no guarantees, and no retransmission. It’s significantly faster. Use it when speed and real-time performance matter more than perfection.

Ports identify which application on a device should receive incoming data. Well-known ports like 80 (HTTP), 443 (HTTPS), 22 (SSH), and 53 (DNS) are standardized across the internet.

QUIC is a modern protocol combining UDP’s speed with TCP-like reliability, the foundation of HTTP/3.

Follow along so you don’t miss it.