The transport layer (layer 4) decides how data gets from one program to another on top of IP: whether it must arrive, whether order matters, and how fast to send. Other transport protocols exist (QUIC, which runs over UDP and underpins HTTP/3, is the notable one), but for system design you mainly need to know two: TCP and UDP.
UDP: fast but unreliable#
UDP (User Datagram Protocol) just fires packets at a destination. You set the source and destination ports and hope for the best. There's no setup, no confirmation and no reordering.
UDP in four points
- Connectionless: no handshake before sending.
- No delivery guarantee: packets can be lost without anyone being told.
- No ordering: packets can arrive in a different order than sent.
- Low latency: less overhead means faster transmission.
UDP fits when speed matters more than completeness: live video, online games, voice calls (VoIP) and DNS lookups. In these cases the application can cope with an occasional lost or out-of-order packet. A missing video frame is better than a frozen picture while you wait for it.
TCP: reliable, with overhead#
TCP (Transmission Control Protocol) guarantees that bytes arrive, in order, without duplicates or corruption. That reliability costs extra round trips and bookkeeping.
- Connection-oriented: a three-way handshake (SYN, SYN-ACK, ACK) sets up a connection before any data moves.
- Reliable delivery: the receiver acknowledges data. Anything not acknowledged is resent.
- Ordering: two messages sent on the same connection arrive in the order they were sent.
- Flow control: the sender slows down so it doesn't overwhelm the receiver.
- Congestion control: the sender backs off when the network is congested, which keeps the internet from collapsing under load.
Comparison#
Side by side, the two protocols trade reliability for speed.
| Feature | UDP | TCP |
|---|---|---|
| Connection | Connectionless | Connection-oriented |
| Reliability | Best effort | Guaranteed delivery |
| Ordering | None | Preserved |
| Flow control | No | Yes |
| Congestion control | No | Yes |
| Header size | 8 bytes | 20–60 bytes |
| Speed | Faster | Slower due to overhead |
| Use cases | Streaming, gaming, VoIP, DNS | Almost everything else |
When to choose which#
Use TCP by default. Choose UDP only when:
- Low latency is critical (real-time apps, games).
- Losing some data is acceptable (live media, voice).
- You're sending high-volume telemetry or metrics where an occasional lost sample is fine.
- You don't need to support web browsers, or you have a fallback for them.
The browser and UDP problem#
Browsers (Chrome, Safari, Firefox) don't let JavaScript open raw UDP sockets, for security reasons. The exception is WebRTC, which uses UDP for peer-to-peer audio and video, but it is complex to set up just to send small pieces of data.
So for high-frequency, low-priority data (live reactions, heartbeats, game positions) you often split by client:
- Native mobile apps: use UDP for a real-time feel with minimal overhead.
- Web browsers: fall back to WebSockets (TCP) or long polling (HTTP).
- Batch on the server: because TCP is heavier, don't forward every event. Instead of sending 100 separate "heart" messages, send one message every 500 ms:
{"hearts": 100}.
Example: a million viewers tapping "like" on a live stream. Mobile clients send likes over UDP for the lowest latency. Browser clients use WebSockets. The backend aggregates likes and pushes one summary update every few hundred milliseconds instead of flooding clients with thousands of tiny messages.
Key takeaways#
- TCP guarantees delivery, order and no duplicates, at the cost of handshakes and overhead.
- UDP is connectionless and fast, with no guarantees. The application handles any loss.
- Default to TCP. Pick UDP for real-time media, games and loss-tolerant telemetry.
- Browsers can't use raw UDP. Use WebRTC, or WebSockets with server-side batching.