TCP vs UDP
TCP and UDP are the two main transport protocols of the internet. TCP sets up a connection and guarantees that bytes arrive in order; UDP fires packets and forgets about them. Pick TCP when correctness matters more than milliseconds, and UDP when the opposite is true.
Last reviewed on 2026-04-27.
Quick Comparison
| Aspect | TCP | UDP |
|---|---|---|
| Full name | Transmission Control Protocol | User Datagram Protocol |
| Model | Connection-oriented (handshake first) | Connectionless (just send) |
| Reliability | Guaranteed delivery, in order | Best effort; packets can be lost, duplicated, reordered |
| Flow / congestion control | Built in | None — the application handles it |
| Header overhead | 20 bytes minimum | 8 bytes |
| Speed and latency | Slower; setup and acknowledgements add overhead | Lower latency, less overhead |
| Typical use cases | Web pages, email, file transfer, SSH, databases | DNS lookups, voice/video calls, online games, streaming, telemetry |
| Builds on top of | IP (the network layer) | IP (the network layer) |
Key Differences
1. Connection model
TCP begins every conversation with a three-way handshake: SYN, SYN-ACK, ACK. Until those three packets complete, no application data flows. This costs a round trip but guarantees that both sides exist, agree on starting sequence numbers, and are ready to talk.
UDP has no handshake. The first packet a sender emits is also the first packet the receiver sees. There's no concept of an open connection, so there's nothing to tear down — and nothing to interrupt if the receiver isn't there.
2. Reliability and ordering
TCP numbers every byte and acknowledges what arrives. Anything missing is retransmitted. The receiver hands data to the application in the exact order it was sent, even if packets travelled by different routes and arrived out of order.
UDP offers no acknowledgements, no retransmissions, and no ordering. A datagram either arrives, is silently dropped by a router, or arrives twice. If those failures matter, the application — not the protocol — has to detect and handle them.
3. Flow and congestion control
TCP watches the network. If packets are getting lost, it slows down; if the receiver is processing slowly, it backs off. This protects shared infrastructure from collapse but means a single TCP flow can't simply fill a fast pipe — it has to ramp up.
UDP sends as fast as the application asks. That's powerful and dangerous: a poorly written UDP application can flood a network. Real UDP-based protocols (QUIC, RTP, modern game protocols) typically rebuild congestion control on top of UDP, but the protocol itself doesn't enforce it.
4. Header size and overhead
TCP headers start at 20 bytes and carry sequence numbers, acknowledgement numbers, window sizes, and option fields. The TCP layer also has to track per-connection state — open sockets, retransmission timers, sliding windows — which costs memory at scale.
UDP headers are 8 bytes: source port, destination port, length, and checksum. There's no per-connection state on either side, which is why a single DNS resolver can serve thousands of UDP queries per second on modest hardware.
5. Latency profile
TCP trades latency for guarantees. The handshake adds at least one round trip before the first byte; lost packets stall the whole stream until they're recovered (head-of-line blocking).
UDP is "send and pray" — the first packet is the first packet, and a lost frame in a video call just becomes a glitch the codec papers over. For real-time work, an old-but-still-arrived packet is useless; UDP lets the application skip it instead of waiting.
6. Security context
Both protocols are unencrypted on their own. TCP is typically wrapped in TLS to give you HTTPS. UDP is wrapped in DTLS or, increasingly, replaced by QUIC — a UDP-based protocol that provides TCP-like reliability and TLS-grade security with lower handshake latency. HTTP/3 runs on QUIC, which runs on UDP.
When to Use Each
Choose TCP if:
- Every byte must arrive, and order matters (web pages, file transfer, database queries).
- You're willing to spend a round trip on setup before sending data.
- You want the protocol to handle retransmissions and congestion for you.
- Your application can tolerate occasional pauses while a lost packet is recovered.
Choose UDP if:
- Real-time delivery beats perfect delivery (voice, video, games, telemetry).
- The exchange is tiny and one-shot (DNS query, NTP time sync).
- You're sending the same data to many receivers (multicast, broadcast).
- You need full control over retransmission and pacing logic.
Worked example: a video call vs an email
Video call (UDP). Each video frame is a datagram. If frame 47 is dropped on the way, frame 48 is already half a second behind it; waiting and retransmitting frame 47 would just make the whole call lag. The codec uses surrounding frames to mask the loss, and the call carries on. UDP's "throw it and move on" semantics fit exactly.
Email attachment (TCP). A 10 MB attachment cannot tolerate any byte going missing — the file would be corrupt. TCP segments the attachment, retransmits anything lost, reassembles in order, and only then hands it to the email client. The user pays a slightly higher latency and gets a guaranteed-correct file.
Common Misconceptions
- "UDP is always faster than TCP." UDP has lower per-packet overhead, but on a high-quality link with cached connections, TCP throughput is typically constrained by the network, not the protocol. UDP wins on latency for short, real-time exchanges, not on raw throughput for bulk transfer.
- "TCP is reliable, so UDP is unreliable." UDP is unreliable on its own; the applications running over UDP often add their own reliability where they want it (selective retransmission, forward error correction). QUIC, used by HTTP/3, is built on UDP and is at least as reliable as TCP.
- "HTTP always means TCP." HTTP/1.1 and HTTP/2 run over TCP. HTTP/3 runs over QUIC, which runs over UDP. The distinction is invisible to most users.
- "DNS is UDP." DNS uses UDP for short queries and TCP when responses are large or when reliability is needed (zone transfers, DNSSEC responses that exceed the UDP size limit).
Decision Checklist
Before choosing a transport for a new protocol or application:
- Is the exchange interactive and time-bounded (a glitch is preferable to a delay)? Lean UDP.
- Is the payload large and order-sensitive? Lean TCP.
- Will the connection persist for many messages? TCP's handshake amortizes well.
- Is the message pattern one query, one response? UDP avoids the handshake cost entirely.
- Do you need encryption and reliability with low latency, on top of UDP? Look at QUIC instead of building it yourself.