Networking protocols comparison
TCP vs UDP
The two transport-layer protocols that underpin almost all internet communication. Understanding the trade-off between reliability and speed comes up in backend architecture discussions, system design interviews, and any conversation about real-time applications.
TL;DR
- TCP — connection-oriented, reliable, ordered. Every byte arrives exactly once, in order. The handshake and acknowledgement machinery add latency and overhead. Used by HTTP, HTTPS, SSH, SMTP.
- UDP — connectionless, fast, unreliable. Packets may be lost, duplicated, or arrive out of order — no guarantees. Used by DNS, video/audio streaming, gaming, WebRTC.
- The right choice depends on whether your application needs every byte, or needs every byte fast.
Side-by-side comparison
| Aspect | TCP | UDP |
|---|---|---|
| Reliability | Guaranteed — lost packets are retransmitted | Best-effort — lost packets are not retransmitted |
| Ordering | Strict — bytes arrive in the order sent | None — packets may arrive out of order |
| Connection | Connection-oriented — three-way handshake required | Connectionless — no setup, just send datagrams |
| Speed / overhead | Higher overhead — ACKs, flow control, congestion control | Low overhead — minimal header (8 bytes) |
| Use cases | HTTP/S, SSH, email, file transfer | DNS, video streaming, VoIP, gaming, WebRTC |
| Error detection | Built-in — checksum + ACK + retransmit | Checksum only — detection but no correction |
| Congestion control | Yes — backs off under network congestion | No — can overwhelm the network |
| Header size | 20–60 bytes | 8 bytes |
When to use TCP
- Data integrity is critical. File transfers, database replication, API calls — every byte must arrive correctly. TCP's retransmission guarantees this automatically.
- Order matters. HTML pages, JSON responses, and source code must arrive in order. TCP's sequencing handles this for you.
- You are building standard web services. HTTP/1.1 and HTTP/2 run over TCP; this is the default for web servers, REST APIs, and most backend communication.
When to use UDP
- Latency beats reliability. Live video, VoIP, and online games cannot tolerate TCP's retransmission delay — a late packet is worse than a missing one.
- Small, frequent messages. DNS queries are tiny and need fast responses; the overhead of a TCP handshake per query would be wasteful.
- Broadcasting or multicasting. UDP supports sending one packet to many recipients simultaneously; TCP requires a separate connection per recipient.
- You implement reliability yourself. Protocols like QUIC (HTTP/3) and game networking SDKs build selective retransmission on top of UDP to get the best of both worlds.
English phrases engineers use
TCP conversations
- "TCP guarantees delivery — if the packet is lost, it gets retransmitted."
- "The handshake adds latency — about one RTT before data flows."
- "We're seeing head-of-line blocking on HTTP/2 — considering HTTP/3."
- "TCP's congestion control backs off when the network is saturated."
- "The connection is torn down with a FIN/ACK exchange."
UDP conversations
- "UDP packets can arrive out of order — we handle sequencing in the application."
- "We're streaming over UDP for low latency — dropped frames are acceptable."
- "DNS uses UDP because the query fits in one datagram."
- "The game server uses UDP and implements its own ACKs for critical state."
- "WebRTC runs over UDP via DTLS and SRTP for encrypted media."
Key vocabulary
- Three-way handshake — TCP's connection setup: SYN → SYN-ACK → ACK before data can flow.
- ACK (acknowledgement) — a TCP signal confirming that data was received; missing ACKs trigger retransmission.
- Datagram — a self-contained UDP packet; each is independent, with no guaranteed delivery or ordering.
- RTT (Round-Trip Time) — the time for a packet to travel from sender to receiver and back; affects perceived latency.
- Head-of-line blocking — TCP's requirement that bytes arrive in order means a lost packet blocks all subsequent bytes until it is retransmitted.
- QUIC — a UDP-based transport protocol used by HTTP/3 that implements reliable, ordered, multiplexed streams with modern congestion control.
- Congestion control — TCP's mechanism for reducing send rate when packets are lost, preventing network collapse.
Quick decision tree
- Web API, file transfer, SSH → TCP
- Live video or audio streaming → UDP
- Online multiplayer game → UDP (often with custom reliability)
- DNS queries → UDP
- HTTP/1.1 or HTTP/2 → TCP
- HTTP/3 → UDP (via QUIC)
- Need broadcast to multiple recipients → UDP
Frequently asked questions
Why does video streaming use UDP?
Video streaming prioritises timeliness over perfect delivery. A lost packet in a video stream just causes a brief visual glitch — the viewer can tolerate that. But if TCP retransmitted every lost packet, stale frames would arrive late, causing buffering and stuttering. UDP lets the application decide what to do with loss (typically: skip it and move on). Protocols like RTP (Real-time Transport Protocol) and WebRTC use UDP for exactly this reason.
What is the three-way handshake?
The TCP three-way handshake establishes a connection before any data is sent. Step 1: the client sends a SYN packet. Step 2: the server responds with SYN-ACK. Step 3: the client sends ACK. Only after this exchange can data flow. This adds one round-trip of latency before the first byte of application data — a meaningful cost on high-latency links. TLS adds further handshake round trips on top.
Does HTTP use TCP?
HTTP/1.1 and HTTP/2 use TCP. HTTP/3 (QUIC) uses UDP — but QUIC implements its own reliable, ordered delivery and congestion control on top of UDP, essentially rebuilding the useful parts of TCP in user space with modern improvements. So HTTP/3 gets UDP's speed advantages while still delivering reliable, ordered streams.
Can UDP be made reliable?
Yes, by implementing reliability at the application layer. QUIC (used by HTTP/3) does this. Game networking libraries, VoIP protocols, and custom game servers often build selective retransmission and acknowledgement on top of UDP so they get reliability for critical data (game state) while skipping retransmission for time-sensitive data (position updates).
What is head-of-line blocking in TCP?
TCP delivers bytes in order. If packet 5 is lost, packets 6, 7, and 8 sit in the receive buffer and cannot be delivered to the application until packet 5 is retransmitted and arrives. This is head-of-line blocking. In HTTP/2 multiplexing multiple streams over one TCP connection, a single lost packet blocks all streams — one of the main motivations for HTTP/3 over QUIC, which has per-stream loss recovery.
Which protocol does DNS use?
DNS uses UDP by default for queries and responses, because DNS messages are typically small (under 512 bytes), and the overhead of a TCP handshake per query would be wasteful. DNS falls back to TCP for large responses (e.g., zone transfers, DNSSEC-signed responses that exceed UDP payload limits). The DNS-over-HTTPS and DNS-over-TLS standards use TCP/TLS for privacy.