The Core Difference in One Sentence
TCP and UDP are both transport-layer protocols that run on top of IP, but they make opposite trade-offs: TCP sacrifices some speed for reliability, while UDP sacrifices reliability for speed. Every internet application that moves data between two machines uses one or the other — and the choice shapes everything about how that application behaves under real network conditions.
TCP (Transmission Control Protocol) is connection-oriented. Before a single byte of application data is sent, TCP establishes a connection through a three-way handshake, synchronizing sequence numbers so both sides can track exactly what has been delivered. UDP (User Datagram Protocol) is connectionless. It wraps your data in a datagram and sends it without any setup, any confirmation, or any knowledge of whether it arrived.
How TCP Works: Reliability at a Cost
TCP delivers a reliable, ordered byte stream by implementing several mechanisms on top of IP's best-effort delivery. First, every TCP session begins with a handshake: the client sends SYN, the server replies with SYN-ACK, and the client confirms with ACK. Both sides are now synchronized and data can flow.
Acknowledgments ensure no data is silently lost. The receiver sends an ACK for each segment. If the sender's timeout expires without an acknowledgment, it retransmits the segment. Sequence numbers label every byte so the receiver can reorder out-of-sequence arrivals and deliver a clean stream to the application above.
TCP also handles backpressure through flow control — slowing when the receiver's buffer fills — and adapts to network congestion by monitoring round-trip times and packet loss, easing off when the path is overloaded. This prevents TCP senders from flooding the network with packets that will just be dropped and retransmitted in a cycle.
The cost is real: the handshake alone adds one round-trip of latency before any data flows. Acknowledgment processing adds CPU work. And when a packet is lost, TCP must wait for the retransmission to arrive before delivering any subsequent data to the application, because the stream must stay in order — a phenomenon called head-of-line blocking.
How UDP Works: Speed Without Guarantees
UDP is deliberately minimal. Its header contains just four fields: source port (2 bytes), destination port (2 bytes), length (2 bytes), and checksum (2 bytes). There is no connection setup, no sequence numbers, no acknowledgments, no retransmission, no congestion control.
When an application sends a UDP datagram, the OS wraps it in a UDP header, hands it to IP, and moves on. The application has no built-in way to know whether the datagram arrived. If it is lost, duplicated, or arrives out of order, UDP does not react. The checksum can detect bit errors, but rather than trigger retransmission, corrupted datagrams are simply discarded.
This sounds like a disadvantage, and for some workloads it is. But for latency-sensitive applications — live video, voice calls, real-time games — the ability to send immediately without a handshake, and without stalling on retransmissions, is exactly what makes UDP the right choice. Applications that need partial reliability implement it themselves on top of UDP, adding only the mechanisms they actually need.
TCP vs UDP Comparison
| Feature | TCP | UDP |
|---|---|---|
| Connection type | Connection-oriented (three-way handshake) | Connectionless |
| Delivery guarantee | Yes — retransmits lost data | No — fire and forget |
| Order guarantee | Yes — reorders out-of-sequence data | No — packets may arrive in any order |
| Error checking | Checksum + retransmission on failure | Checksum only (errors silently discarded) |
| Speed overhead | Higher — handshake, ACKs, congestion control | Lower — minimal header, no setup |
| Retransmission | Automatic | None (application must handle if needed) |
| Use cases | HTTP/1.1, HTTP/2, email, file transfer, SSH | DNS, VoIP, gaming, live streaming, QUIC |
Real-World Use Cases
The choice between TCP and UDP comes down to what the application values more — correctness or latency. TCP is used for web browsing (HTTP/1.1 and HTTP/2 run over TCP), email (SMTP, IMAP, POP3), file transfers (FTP, SFTP), remote shells (SSH), database connections, and any application where losing or corrupting data is unacceptable.
UDP is used for DNS lookups (a query that fits in one packet does not need TCP's overhead), VoIP and video conferencing, live video streaming, online gaming, NTP (network time synchronization), DHCP (IP address assignment), and QUIC — the protocol underlying HTTP/3 — which implements its own reliability and congestion control on top of UDP, avoiding the limitations of the kernel TCP stack.
Why Games Use UDP Even Though Packets Get Lost
Real-time games require that player actions and world state arrive with minimum delay. When a player moves or fires, that event needs to reach all other players within milliseconds. TCP's retransmission mechanism creates a problem: when a packet is lost, TCP stalls the data stream until the missing segment is retransmitted and received — because it guarantees ordered delivery. This head-of-line blocking can freeze the game state for hundreds of milliseconds while a single dropped packet is recovered.
Games using UDP take a different approach: they simply discard stale packets. A position update from 150ms ago is worse than useless — the player has moved since then. It is better to skip it entirely and display the next update, which arrives just 16ms later at 60 updates per second. Game engines implement selective reliability on top of UDP for events that absolutely cannot be lost (player deaths, item pickups), while high-frequency state updates like position and animation fly as fire-and-forget datagrams. The result is a responsive game that degrades gracefully under packet loss rather than freezing.
Frequently Asked Questions
Is TCP or UDP faster?
UDP is faster in practice because it has no connection setup, no acknowledgment overhead, and no retransmission delays. TCP's reliability mechanisms add latency — the three-way handshake alone adds one round trip before any data is sent. For latency-sensitive applications, UDP's lower overhead is the reason it is chosen.
Which is more reliable, TCP or UDP?
TCP is far more reliable. It guarantees delivery, ordering, and error checking with retransmission of lost data. UDP makes no such guarantees — packets can be lost, duplicated, or arrive out of order with no notification to the application. Any reliability in a UDP-based system must be implemented by the application itself.
Do games use TCP or UDP?
Most real-time online games use UDP for game state updates because the low latency matters more than guaranteed delivery. A position update from 100ms ago is worthless by the time it arrives — it is better to drop it and use the next one. Games typically handle their own reliability for critical events like player actions.
Does DNS use TCP or UDP?
DNS uses UDP port 53 for most queries because responses are small and fast. If a DNS response is too large to fit in a single UDP datagram, DNS falls back to TCP. DNS zone transfers always use TCP because they transfer large amounts of data reliably.
Can UDP packets arrive out of order?
Yes. UDP provides no ordering guarantee. Packets can take different paths through the network and arrive in any order, or not at all. Applications that need ordering on top of UDP must implement their own sequence numbers and reordering logic.
What happens if a UDP packet is lost?
Nothing, automatically. UDP has no retransmission mechanism. If a UDP packet is lost in transit, neither the sender nor the receiver is notified. The packet is simply gone. Applications that need reliability over UDP must detect loss themselves using sequence numbers and timeouts, then decide whether to retransmit.