What is the difference between TCP and UDP, and when would you pick each one?
Show the answer
Say this first
TCP gives the application a connection and a reliable, ordered byte stream, with flow control and congestion control. It pays for that with a handshake and with waiting for retransmissions. UDP adds only ports, a length and a checksum to IP: no connection, no retransmission, no ordering, and it keeps message boundaries. I pick TCP when every byte must arrive in order (web, SSH, BGP, databases, file transfer) and UDP when late data is useless or the application wants its own reliability (voice and video over RTP, DNS queries, DHCP, NTP, QUIC).
Go deeper
Side by side
| TCP | UDP | |
|---|---|---|
| Setup | Three-way handshake | None |
| Delivery | Reliable, in order, duplicates removed | Best effort, may be lost, duplicated or reordered |
| Unit | Byte stream (no message boundaries) | Datagram (one send, one receive) |
| Flow control | Receive window | None |
| Congestion control | Yes (CUBIC, BBR and others) | None, the application must behave |
| Header | 20 to 60 bytes | 8 bytes |
| Multicast and broadcast | No | Yes |
| IP protocol number | 6 | 17 |
How I decide
- Does late data still have value? A retransmitted voice sample arrives after the jitter buffer has played the gap. For real-time media, a lost packet is better than a late one, so RTP runs on UDP.
- Is the exchange one small question and answer? DNS, NTP and SNMP fit in one datagram each way. A handshake would double the latency for no gain. DHCP has another reason: the client has no IP address yet and must broadcast.
- Do I need one-to-many? Multicast and broadcast only work with UDP.
- Do I want reliability but not TCP's behaviour? QUIC builds streams, retransmission and congestion control on top of UDP in user space, so it can evolve without kernel or middlebox changes.
- Everything else that must be complete and correct goes on TCP.
They will ask next
Does DNS only use UDP?
No. DNS uses UDP 53 for normal queries and TCP 53 when a response is too big (the server sets the TC bit and the client retries over TCP), for zone transfers (AXFR and IXFR), and for DNS over TLS on TCP 853. A firewall that allows only UDP 53 breaks large answers, often DNSSEC ones.
How does a firewall or NAT keep state for UDP if there is no connection?
It creates a flow entry on the first packet and removes it after an idle timeout. There is no FIN to watch, so the timeout is the only end. On IOS NAT the default UDP translation timeout is 300 seconds. Applications that go quiet for longer than the timeout send their own keepalives.
If UDP has no congestion control, what stops a UDP application from flooding the network?
Only the application. Well-behaved UDP protocols add their own rate control: QUIC has full congestion control, RTP media adapts its bitrate from RTCP feedback. Badly behaved ones are why operators police UDP and why QoS designs put real-time traffic in a strict priority queue with a policer.
Traps
- Saying UDP is "worse" because it is unreliable. It is a different tool: lower latency, no state, multicast.
- Saying TCP guarantees delivery. It guarantees that the application gets the data in order or gets an error.