Overview
TCP and UDP are the two main transport protocols. TCP provides a reliable, ordered byte stream: it sets up a connection with a three-way handshake, numbers every byte, retransmits lost packets, and controls speed to avoid overwhelming the receiver or the network. UDP simply sends independent datagrams with no connection, ordering, or retransmission.
The choice is a trade-off between reliability and latency. TCP powers HTTP/1.1 and HTTP/2, databases, and SSH. UDP powers DNS, video calls, online games, and QUIC (the basis of HTTP/3), where a late packet is useless or the application wants to control reliability itself.
TCP is registered mail: every item is tracked, signed for, and resent if lost, delivered in order. UDP is shouting across a field: fast and simple, but if someone misses a word, you do not repeat it; you keep talking.
When to use it
- TCP: correctness matters more than a few milliseconds (web pages, payments, file transfer, databases).
- UDP: real-time data where old packets are worthless (voice, video, games, live metrics).
- UDP: small request-response exchanges where a connection is overkill (DNS).
- UDP + custom reliability: modern protocols like QUIC that avoid TCP's head-of-line blocking.
Where it shows up in interviews
Recognize it when: voice, video, gaming, live location where freshness beats completeness.
- Design a video conferencing system
- Design a multiplayer game server
- Design Uber live location
Recognize it when: millions of long-lived connections.
- Design WhatsApp
- Design a notification push service
Where it is used in real software
Video calls send media over UDP (RTP/SRTP) and adapt quality instead of waiting for retransmissions.
Google built QUIC on UDP to get reliability per stream, faster handshakes, and connection migration when phones switch networks.
Most DNS queries are a single UDP packet each way; TCP is used for large responses and zone transfers.
Key terms
- Three-way handshake
- SYN, SYN-ACK, ACK: establishes a TCP connection in one round trip.
- Sequence number / ACK
- Numbers bytes so the receiver can order data and acknowledge what arrived.
- Flow control
- The receiver advertises a window of how much it can accept.
- Congestion control
- The sender slows down when the network shows loss or delay (Cubic, BBR).
- Head-of-line blocking
- One lost packet stalls all later data on a TCP connection until it is retransmitted.
TCP connection lifecycle
- 1SYN
The client sends SYN with its initial sequence number.
- 2SYN-ACK
The server acknowledges and sends its own sequence number.
- 3ACK
The client acknowledges; data can flow. Cost: one round trip.
- 4Data transfer
Segments are acknowledged; missing ones are retransmitted; the window grows during slow start.
- 5Teardown
FIN / ACK from each side closes the connection; the closer waits in TIME_WAIT briefly.
STEP 1The client sends SYN (seq = x) to open a connection.
TCP vs UDP side by side
Choose per use case
| Property | TCP | UDP |
|---|---|---|
| Connection | Handshake required | None |
| Reliability | Retransmits lost data | No guarantees |
| Ordering | In-order byte stream | Datagrams may reorder |
| Header size | 20-60 bytes | 8 bytes |
| Congestion control | Built in | Application's responsibility |
| Typical uses | HTTP/1.1, HTTP/2, SQL, SSH | DNS, video, games, QUIC |
NOWProperty: Connection | TCP: Handshake required | UDP: None
TCP trades latency for correctness; UDP gives you raw speed and leaves reliability decisions to the application.
Implementation
import net from "node:net";import dgram from "node:dgram"; // TCP echo server: reliable, ordered stream per connectionnet.createServer((socket) => { socket.on("data", (chunk) => socket.write(chunk));}).listen(7000); // UDP server: independent datagrams, no connectionconst udp = dgram.createSocket("udp4");udp.on("message", (msg, remote) => { udp.send(msg, remote.port, remote.address); // may be lost; no retransmission});udp.bind(7001);Complexity and performance
Plus TLS if encrypted.
Send immediately.
Servers handle millions with tuning.
Trade-offs
Retransmitting a lost video frame 200 ms later is pointless; retransmitting a missing bank transfer byte is essential.
HTTP/2 multiplexes streams on one TCP connection, so one lost packet stalls all streams. QUIC solves this with independent streams over UDP.
Variants and related techniques
UDP-based transport with built-in TLS 1.3, per-stream reliability, and connection migration.
Full-duplex messaging over a TCP connection upgraded from HTTP.
keep-alive, Nagle's algorithm (TCP_NODELAY), and BBR congestion control affect latency and throughput.
Common mistakes
- Opening a new TCP connection per request.
Fix: Reuse connections with keep-alive and connection pools.
- Assuming UDP packets arrive in order.
Fix: Add sequence numbers if order matters.
- Treating TCP messages as delimited.
Fix: TCP is a byte stream; frame messages with a length prefix or delimiter.
Interview questions
Why do video calls use UDP?
A late frame is useless. UDP lets the app drop late packets and adapt bitrate instead of stalling to retransmit, keeping latency low.
What is head-of-line blocking?
In TCP, data must be delivered in order, so a single lost packet blocks all data after it until it is retransmitted, even data belonging to unrelated HTTP/2 streams.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Explain the 3-way and 4-way handshakes | Easy | Connection lifecycle. |
| Choose transports for a ride-hailing app's features | Medium | Per-feature trade-offs. |
| Design a real-time multiplayer game network layer | Hard | UDP with custom reliability. |