TCP vs UDP: Why Some Apps Want Reliability and Others Want Speed

This content originally appeared on DEV Community and was authored by Naval Kishor Upadhyay

Every time you stream a video, send a message, or download a file, your data travels across the internet using one of two transport protocols: TCP or UDP.

Both live at the Transport Layer (Layer 4) of the OSI model, and both serve the same basic purpose: getting data from one application to another. But they do it in very different ways.

Let’s explore the core mechanics of each, with step-by-step examples so you can see them in action.

TCP in Action: Downloading a File

Imagine you’re downloading a PDF file from example.com. Here’s what happens:

1. Connection Setup (3-Way Handshake)

   • Your laptop sends a SYN message to the server → “I’d like to talk, here’s my starting number.”
   • The server responds with SYN-ACK → “Got it, here’s my number, and I accept yours.”
   • Your laptop replies with ACK → “Great, connection confirmed.” Now a reliable connection exists.

2. Data Transfer Begins

   • The server starts breaking the PDF into segments (chunks of data).
   • Each segment has a sequence number (like page numbers).

3. Acknowledgments

   • Your laptop receives segment #1 and replies: “ACK 2” → meaning “I got segment 1, now send me #2.”
   • If segment #2 is lost, your laptop never sends ACK 3.
   • The server notices the missing ACK and retransmits segment #2.

4. Flow Control

   • If your Wi-Fi is slow, your laptop can tell the server: “Only send 2 segments at a time.”
   • This prevents overload and dropped data.

5. Reassembly

   • Once all segments arrive, TCP puts them in order to rebuild the PDF.

6. Connection Teardown

   • After the file is delivered, TCP closes the connection gracefully with a FIN/ACK exchange.

Result: You always get the complete PDF, in the right order, even if some packets were lost or delayed along the way.

UDP in Action: Streaming a Live Football Match

Now imagine you’re streaming a football match on your phone using a service like YouTube Live. Here’s how UDP handles it:

1. No Handshake

   • Your phone simply starts requesting the video stream.
   • The server immediately begins sending datagrams (video chunks).

2. Independent Packets

   • Each datagram contains part of the video feed.
   • Unlike TCP, there are no sequence numbers or guarantees.

3. Lost Packet? No Problem

   • If datagram #37 (a few frames of video) gets lost, the server won’t resend it.
   • Your phone just plays the next available frame.
   • You might see a tiny glitch, but the stream continues smoothly.

4. Out-of-Order Packets

   • Datagram #40 might arrive before #39.
   • Your phone’s media player either drops the late one or adjusts playback on the fly.

5. Continuous Flow

   • The focus is on speed and low latency.
   • The goal is “show me the game live,” not “make sure I see every single frame.”

Result: The match plays in real time with minimal delay, even if a few frames are lost. That’s far better than pausing every few seconds waiting for missing packets.

Core Difference: Reliability vs Speed

Final Thoughts

• TCP is about trust — it makes sure that every bit of your file, email, or webpage arrives intact and in order.
• UDP is about speed — it prioritizes real-time experience, even if it means losing a packet or two along the way.

So the next time you download a file or watch a live stream, remember:

• That PDF reached you thanks to TCP’s reliability.
• That football match stayed live thanks to UDP’s speed.

Both protocols are invisible to you, but they shape your internet experience every single day.

This content originally appeared on DEV Community and was authored by Naval Kishor Upadhyay