TCP sets up a session, numbers every packet, and retransmits anything that gets lost. UDP just throws packets and walks away. Both ride on top of IP. The choice between them is the choice between “guaranteed correct” and “fast no matter what.”
The core trade-off
- TCP — connection-oriented. Three-way handshake to start a session, sequence numbers to order packets, ACKs to confirm delivery, retransmission for missing packets. Reliable but adds latency.
- UDP — connectionless. Send a datagram, hope it arrives, move on. No setup, no ordering, no delivery guarantee. Fast and tiny but you handle reliability yourself if you need it.
What uses each
- TCP: HTTP/HTTPS, SSH, FTP, SMTP/IMAP/POP3, anything where every byte matters.
- UDP: DNS, NTP, DHCP, VoIP (SIP, RTP), online gaming, video streaming (RTP), QUIC.
- Both: A few — DNS uses UDP normally, TCP for big responses or zone transfers. NFS, SIP, and a few others negotiate.
Why latency-sensitive things use UDP
Imagine a video call drops one packet. With TCP, the next packets queue while the lost one retransmits — adding 50–200ms of latency. With UDP, the next packets arrive on time and the application just shows a brief glitch. For real-time, glitchy is better than late.
See whether a given port is TCP, UDP, or both — and what service runs on it.
QUIC — having it both ways
HTTP/3 runs on QUIC, which is built on UDP but adds reliability, ordering, encryption, and multiplexing in the application layer. Combines TCP’s guarantees with UDP’s setup speed (1-RTT or 0-RTT vs TCP’s 3-way handshake + TLS handshake). Most major web services have adopted it; some networks still block UDP, which means fallback to TCP/TLS/HTTP/2.
Picking one for your own app
Default to TCP. The reliability is free at the protocol level, and you don’t want to hand-roll retransmission unless you have a real reason. Reach for UDP when latency matters more than completeness, when you’re doing broadcast/multicast, or when you’re building on top of QUIC and don’t care about the underlying transport.