TL;DR
TCP is connection-oriented and guarantees reliable, ordered delivery with flow and congestion control — right for HTTP/HTTPS, databases, and file transfer. UDP is connectionless with no reliability or ordering guarantees, but has small headers and low latency — right for DNS, video calls, real-time games, and NTP. Choose based on three questions: can you tolerate packet loss, does ordering matter, and how latency-sensitive are you?
Comparison
| Aspect | TCP | UDP |
|---|---|---|
| Connection setup | 3-way handshake (SYN/SYN-ACK/ACK) | None |
| Reliability | Retransmission, delivery guaranteed | Not guaranteed |
| Ordering | Ordered byte stream | Not guaranteed |
| Header size | 20–60 bytes | 8 bytes |
| Flow/congestion control | Yes | No |
| Common uses | HTTP 80, HTTPS 443, SSH 22, SMTP 25, MySQL 3306 | DNS 53, NTP 123, DHCP 67/68, RTP, QUIC 443 |
How to choose
- Need reliability: TCP. Need low latency plus reliability: QUIC over UDP (HTTP/3).
- Real-time and loss-tolerant: UDP (audio/video, gaming).
- Small stateless queries: DNS over UDP, retransmit on failure.
- Need multiplexing, 0-RTT, or connection migration: QUIC beats TCP.
FAQ
Is TCP always slower than UDP?
Not necessarily. TCP's overhead comes from the handshake and congestion control; for single small requests the difference is tiny, and for long-lived or streaming connections TCP's reliability often reduces app-level retries.
Why does DNS use UDP?
A DNS query is usually one request and one packet; UDP avoids connection overhead. When responses exceed 512 bytes, DNS falls back to TCP (or uses EDNS(0)).
Why is HTTP/3 based on UDP?
HTTP/3 runs on QUIC, which implements reliability, 0-RTT handshakes, multiplexing, and connection migration over UDP, removing TCP head-of-line blocking.
Sources
- RFC 793 (TCP), RFC 768 (UDP), RFC 9000 (QUIC), RFC 9114 (HTTP/3), accessed 2026-08-04
- MDN Web Docs, accessed 2026-08-04