TCP and UDP are the two primary transport layer protocols. TCP prioritizes reliability and data integrity through connection establishment and error checking, while UDP sacrifices those guarantees for speed and lower overhead. Your choice depends entirely on whether your application can tolerate packet loss or needs guaranteed delivery.
Both TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) operate at Layer 4 of the OSI model—the transport layer. They're the mechanisms that applications use to send data across networks, sitting between your application and the IP layer below them.
Think of TCP as registered mail—it confirms delivery, tracks what was sent, and resends anything that got lost. UDP's more like shouting across a room: it sends the message once and doesn't care if everyone heard it. Both have their place, and understanding when to use each will make you a better architect.
TCP establishes a connection before any data moves. This three-way handshake (SYN, SYN-ACK, ACK) ensures both sides are ready to communicate. Once connected, TCP guarantees that every byte arrives in the correct order, and if packets are lost or corrupted, TCP automatically resends them.
Here's what makes TCP reliable:
The tradeoff? TCP's overhead is significant. All those checks, acknowledgments, and retransmissions mean higher latency and more bandwidth consumed per byte of actual data.
Use TCP whenever the application requires every piece of data to arrive correctly. This includes:
If losing even a single packet breaks your application's functionality or could corrupt data, TCP is your protocol.
UDP skips the connection establishment entirely. It simply packages data into datagrams and sends them to the destination address. There's no handshake, no acknowledgment, no retransmission. Send it and move on.
UDP's minimalist approach provides:
The catch is obvious: UDP doesn't guarantee delivery. Packets may arrive out of order, duplicated, or not at all. For applications that can tolerate occasional lost data, UDP's speed advantage is huge.
Use UDP for real-time applications where speed matters more than perfect accuracy:
If you're streaming a video and one frame drops, you don't want TCP holding up subsequent frames while it retransmits the lost one. UDP lets you move forward and accept the occasional pixel glitch.
| Feature | TCP | UDP |
|---|---|---|
| Connection Setup | Three-way handshake required | Connectionless |
| Reliability | Guaranteed delivery | Best-effort delivery |
| Ordering | In-order delivery guaranteed | May arrive out of order |
| Speed | Slower (more overhead) | Faster (minimal overhead) |
| Header Size | 20 bytes (minimum) | 8 bytes |
| Error Checking | Extensive, automatic retransmit | Basic checksum only |
| Broadcasting | Not supported | Supported |
| Memory Usage | Maintains connection state | Minimal state tracking |
Let's look at how your computer establishes a TCP connection. When you visit a website, here's what happens behind the scenes:
1. SYN: Client sends sequence number (e.g., 1000)
Client → Server: SYN (seq=1000)
2. SYN-ACK: Server responds with its own sequence and acknowledges client's
Server → Client: SYN-ACK (seq=2000, ack=1001)
3. ACK: Client acknowledges server's sequence
Client → Server: ACK (seq=1001, ack=2001)
Connection established. Data can now flow.This handshake ensures both sides are alive and synchronized. It adds latency, but guarantees a stable foundation for data transfer. Once established, every segment is numbered and tracked, so the receiver can detect gaps and request retransmission.
UDP is much simpler. For a DNS lookup, the process is:
Client sends UDP packet to DNS server on port 53:
- Source IP: Client's IP
- Destination IP: 8.8.8.8 (Google DNS)
- Destination Port: 53
- Payload: "What's the IP for google.com?"
Server receives, looks up record, sends response immediately.
No connection, no acknowledgment, done.If that packet gets dropped between client and server, the client will simply timeout and retry. It's fast because there's almost no protocol overhead.
Ask yourself these questions:
Many modern applications actually use both. Streaming services may use TCP for initial handshake and metadata, then switch to UDP for actual video frames. This hybrid approach gets the best of both worlds.
If you're working with networking and need to understand the full picture, check out our guide on networking fundamentals to learn how these protocols fit into the larger OSI model. For deeper dives into specific applications, we also cover DNS and how it uses UDP and HTTP/HTTPS which relies on TCP.
"UDP is unreliable." More accurately, UDP is unreliable at the protocol level, but applications using UDP can implement their own reliability mechanisms. Online games do this—they acknowledge critical player actions while ignoring less important movement updates.
"TCP is always better." Not true. TCP's guarantees come at a cost. For real-time applications, that cost (latency) outweighs the benefits of reliability.
"You pick one or the other." Many applications use both. QUIC, a newer transport protocol, actually implements TCP-like reliability over UDP, proving there's room for innovation beyond this binary choice.
Because reliability comes with latency. A 100ms delay in a video call is worse than losing one frame. UDP lets you optimize for what your application actually needs. Speed and throughput matter more for real-time applications than perfect accuracy.
Yes. UDP has no sequencing mechanism. If two packets travel different routes through the network, the second one might arrive before the first. Your application must handle reordering if order matters. Most applications that use UDP either don't care about order or implement their own ordering on top of UDP.
The receiver won't acknowledge it. The sender has a timeout timer—if no acknowledgment arrives within the timeout window, it retransmits the packet. This continues until the packet is successfully delivered or the connection is closed after repeated failures.
UDP is critical infrastructure. DNS (the system that translates domain names to IP addresses) relies on UDP. Network Time Protocol (NTP) uses UDP. SNMP monitoring uses UDP. Many industrial IoT systems use UDP for sensor data. It's everywhere—reliability just isn't the priority for these use cases.