TCP vs UDP
Video releasing soon. System Design 101: Networking, Part 3.
Quick revision
- TCP (Transmission Control Protocol): connection-oriented transport providing a reliable, ordered byte stream.
- UDP (User Datagram Protocol): sends independent datagrams without a transport connection handshake or built-in delivery/order guarantees.
- Both are transport-layer protocols used by applications to communicate across networks.
Remember the download and video-call example
A file download needs all the bytes in the correct order. Missing bytes cannot simply be skipped.
During a live call, a late video frame can be less useful than the latest frame. An application may choose to tolerate some loss rather than wait for old data.
How TCP works
TCP normally establishes a connection using a three-way handshake:
Client -> Server: SYN
Client <- Server: SYN-ACK
Client -> Server: ACK
TCP tracks sequence numbers, acknowledges received data, and retransmits missing data. It reassembles bytes into the correct order before delivering them to the application. Flow control protects the receiver, while congestion control adjusts sending to network conditions. See RFC 9293: TCP.
Use TCP when complete, ordered delivery matters: file downloads, email transport, and HTTP/1.1 or HTTP/2 connections.
How UDP works
UDP sends datagrams without establishing a transport connection first. UDP itself does not acknowledge delivery, retransmit lost packets, or reorder packets for the application. It preserves message boundaries, unlike TCP's byte stream. See RFC 768: UDP.
This smaller protocol overhead and freedom from waiting for missing data can suit live gaming, voice, and real-time video. Applications decide how to handle loss, ordering, and timing.
Choosing in a system design interview
- Choose TCP when missing or out-of-order bytes would make the result unusable.
- Consider UDP-based transport when freshness and application control over latency matter more than recovering every old packet.
- UDP is not automatically faster: network conditions, packet loss, congestion control, and application behavior determine performance.
- TCP reliability does not guarantee the remote application processed or stored your request. That requires application-level acknowledgments and error handling.
Important qualifications
- TCP does not preserve application message boundaries. One write may be received in multiple reads; applications need framing.
- UDP applications can add reliability. QUIC runs over UDP and adds secure connections and reliable streams. See RFC 9000: QUIC.
- HTTP is not always TCP. HTTP/3 uses QUIC. Buffered video streaming over HTTP is different from real-time media delivery. See RFC 9114: HTTP/3.
- Neither plain TCP nor UDP encrypts application data by itself.
Recall: TCP handles ordered, reliable byte delivery; UDP leaves delivery and ordering decisions to the application or a protocol built above it.