Networking Comparison
TCP vs UDP
TCP establishes a connection and guarantees that every byte arrives, in order, retransmitting anything lost; UDP just sends datagrams with no handshake, no ordering and no retries. TCP is right whenever missing data corrupts the result — web, email, file transfer. UDP is right when late data is worse than lost data, as in live voice, video and gaming.
The short answer
Neither is better. TCP when losing data breaks the result; UDP when waiting for a retransmission breaks the experience.
When to choose each
Choose TCP
Connection-oriented, reliable, ordered delivery.
- Every byte must arrive, in order — web pages, files, email, databases
- A missing packet would corrupt the result
- You want flow and congestion control handled for you
- You are not sure — TCP is the correct default
Choose UDP
Connectionless datagrams, no delivery guarantee.
- Late data is worse than lost data — live voice, video, gaming
- Small request-response exchanges where a retry is cheaper than a handshake — DNS
- Broadcast or multicast to many recipients
- You are implementing reliability yourself, as QUIC does
TCP vs UDP: side by side
11 dimensions. A highlighted cell means one side is clearly ahead on that specific point — most rows are trade-offs and score neither.
| Dimension | TCP | UDP |
|---|---|---|
| Connection | Connection-oriented — a three-way handshake before any data moves. | Connectionless — datagrams are sent with no setup at all. |
| Reliability | Guaranteed. Lost segments are detected and retransmitted. | None. A lost datagram is simply gone, and the sender never learns. |
| Ordering | Bytes arrive in the order sent; the stack reassembles them. | No ordering. Datagrams can arrive out of sequence or not at all. |
| Header size | 20 bytes minimum, more with options. | 8 bytes, fixed. |
| Latency | Higher — handshake, acknowledgements and retransmission waits. | Lower — send and forget, with nothing to wait for. |
| Congestion control | Built in; backs off when the network is loaded, protecting everyone. | None. An unthrottled UDP sender can flood a link. |
| Head-of-line blocking | Yes — one lost segment stalls everything behind it. | No — later datagrams are delivered regardless of earlier losses. |
| Broadcast and multicast | Not supported; TCP is strictly point-to-point. | Supported, which is why service discovery uses it. |
| Overhead under loss | Retransmission keeps data intact at the cost of delay. | None — but the application must cope with the gap, or accept it. |
| Typical users | HTTP/1.1 and HTTP/2, SSH, SMTP, FTP, database connections. | DNS, DHCP, NTP, VoIP, live video, gaming, and QUIC (so HTTP/3). |
| Best fit | Anything where a missing byte corrupts the result. | Anything where a late packet is worse than a lost one. |
Connection
TCP
Connection-oriented — a three-way handshake before any data moves.
UDP
Connectionless — datagrams are sent with no setup at all.
Reliability
TCP
Guaranteed. Lost segments are detected and retransmitted.
UDP
None. A lost datagram is simply gone, and the sender never learns.
Ordering
TCP
Bytes arrive in the order sent; the stack reassembles them.
UDP
No ordering. Datagrams can arrive out of sequence or not at all.
Header size
TCP
20 bytes minimum, more with options.
UDP
8 bytes, fixed.
Latency
TCP
Higher — handshake, acknowledgements and retransmission waits.
UDP
Lower — send and forget, with nothing to wait for.
Congestion control
TCP
Built in; backs off when the network is loaded, protecting everyone.
UDP
None. An unthrottled UDP sender can flood a link.
Head-of-line blocking
TCP
Yes — one lost segment stalls everything behind it.
UDP
No — later datagrams are delivered regardless of earlier losses.
Broadcast and multicast
TCP
Not supported; TCP is strictly point-to-point.
UDP
Supported, which is why service discovery uses it.
Overhead under loss
TCP
Retransmission keeps data intact at the cost of delay.
UDP
None — but the application must cope with the gap, or accept it.
Typical users
TCP
HTTP/1.1 and HTTP/2, SSH, SMTP, FTP, database connections.
UDP
DNS, DHCP, NTP, VoIP, live video, gaming, and QUIC (so HTTP/3).
Best fit
TCP
Anything where a missing byte corrupts the result.
UDP
Anything where a late packet is worse than a lost one.
Frequently Asked Questions
Is UDP faster than TCP?
It has lower overhead — no handshake, a smaller header and no waiting for retransmission — so it has lower latency. It is not faster in throughput terms, and on a lossy link TCP often delivers more usable data per second because UDP just loses it. "Faster" here means "lower latency", not "higher bandwidth".
Why does DNS use UDP?
A query and its answer usually fit in one small packet, so a three-way handshake would more than double the cost of the exchange. If the answer is too large, or for a zone transfer, DNS falls back to TCP on the same port number.
Does HTTP/3 use UDP?
Yes. HTTP/3 runs over QUIC, which is built on UDP and reimplements reliability, ordering and congestion control in user space. That let it fix TCP's head-of-line blocking and speed up connection setup without waiting for operating systems to ship a new transport protocol.
Are TCP port 53 and UDP port 53 the same thing?
No. TCP and UDP have entirely separate port number spaces, so TCP/53 and UDP/53 are different endpoints on the same machine. DNS happens to listen on both, which is why the distinction is easy to miss.