UDP

UDP is one of the two main transport protocols on the internet, sitting alongside TCP on top of IP. It was defined in 1980 in RFC 768 and has barely changed since. Its job is to carry application data from one machine to another, and it does the absolute minimum needed to do that.

A unit of UDP data is called a datagram. Each datagram is self-contained: it carries a source port, a destination port, a length, and a checksum, and then the payload. That header is only 8 bytes. TCP's header, by comparison, is 20 bytes or more. There is no concept of a connection. The sender fires a datagram at an address and port and moves on without waiting for anything back.

Because there is no connection state, UDP gives you no guarantees. Datagrams can arrive out of order, arrive twice, or never arrive at all. The protocol will not notice and will not fix it. If your application cares about any of that, your application code has to handle it.

When an application calls send on a UDP socket, the operating system wraps the data in an 8-byte UDP header, hands it to the IP layer, and the packet goes out on the wire. There is no SYN/SYN-ACK/ACK handshake like TCP does before sending data, so the very first packet already carries real payload. This is why a DNS lookup over UDP can complete in a single round trip.

The receiver's OS looks at the destination port to figure out which socket should get the datagram, verifies the checksum, and delivers the payload to whatever process is listening. If the checksum fails, the datagram is silently dropped. There is no signal sent back to the sender about loss, duplication, or reordering.

UDP also does not do flow control or congestion control. TCP slows down when the network is congested or when the receiver is overwhelmed. UDP just keeps sending at whatever rate the application chooses, which is great for predictable real-time media but can flood a network if used carelessly. Modern protocols built on UDP, like QUIC, add their own congestion control on top.

One practical limit: a single UDP datagram larger than the network path's MTU (typically around 1500 bytes on Ethernet) gets fragmented at the IP layer, and if any fragment is lost the whole datagram is lost. Most designs keep datagrams under roughly 1400 bytes to avoid fragmentation.

Reach for UDP when low latency matters more than perfect delivery, and when your data is naturally broken into small independent messages. Live video, voice over IP, multiplayer game state, telemetry, and DNS queries all fit this shape. In a video call, a packet that arrives 300ms late is useless anyway, so retransmitting it the way TCP would only adds delay and jitter. Dropping it and moving on gives a smoother experience.

The trade-off is that you inherit all the hard problems TCP solves for you. If you need ordering, deduplication, or guaranteed delivery, you have to build it in your application or use a higher-level protocol. Many real systems use a hybrid: send the bulk media over UDP for speed, but send a small reliable control channel that re-requests only the packets that actually matter.

Avoid UDP for things like file transfers, database queries, web pages, and API calls, where a single missing byte corrupts the result. Those are exactly what TCP is built for. A useful rule of thumb: if losing a message is acceptable or even preferable to delaying everything behind it, UDP fits.

DNS is the classic case. When your browser needs the IP address for example.com, it sends a small UDP datagram to a DNS resolver on port 53 and waits for one datagram back. The whole exchange is two packets and one round trip, with no handshake overhead. If the reply never comes, the resolver simply retries after a short timeout. DNS only falls back to TCP for responses too large to fit in a single datagram, such as large zone transfers.

Video conferencing shows the trade-off in action. Zoom, Google Meet, and Microsoft Teams send audio and video as RTP over UDP. When the network drops a packet, the codec conceals the gap by repeating the last frame or interpolating, and the call keeps flowing. Forcing that traffic through TCP would cause the dreaded freeze-then-fast-forward effect because every lost packet would stall the entire stream until it was retransmitted.