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:
-
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.
-
Data Transfer Begins
- The server starts breaking the PDF into segments (chunks of data).
- Each segment has a sequence number (like page numbers).
-
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.
-
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.
-
Reassembly
- Once all segments arrive, TCP puts them in order to rebuild the PDF.
-
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:
-
No Handshake
- Your phone simply starts requesting the video stream.
- The server immediately begins sending datagrams (video chunks).
-
Independent Packets
- Each datagram contains part of the video feed.
- Unlike TCP, there are no sequence numbers or guarantees.
-
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.
-
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.
-
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
| Feature | TCP (File Download) | UDP (Live Stream) |
|---|---|---|
| Setup | 3-way handshake, connection established | No handshake, just send data |
| Reliability | Missing packets are retransmitted | Missing packets are ignored |
| Order | Always reassembled in correct order | May arrive out of order |
| Overhead | Higher (extra checks and acknowledgments) | Lower (lightweight headers) |
| User Experience | Guaranteed full file | Real-time, even with glitches |
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.
Top comments (0)