What is UDP? Understanding the “Unreliable” Transport Protocol

When you send a message over the internet—whether it’s a cat meme, a video stream, or a DNS lookup—it’s traveling through layers of protocols. Two of the most important transport-layer protocols in this stack are TCP and UDP. While TCP gets a lot of the spotlight thanks to its reliability and widespread use in web traffic, UDP (User Datagram Protocol) is the unsung hero behind many real-time and low-latency applications. In this post, we’ll demystify what UDP is, how it works, and why developers choose it despite its nickname: the "Unreliable Datagram Protocol." What is UDP? UDP is one of the core protocols of the Internet Protocol (IP) suite. It was introduced in 1980 as a lightweight alternative to TCP. UDP operates on top of IP and is used to send short messages called datagrams. The key difference? UDP doesn’t establish a connection before sending data. It just sends packets and hopes they arrive. This simplicity means: No handshakes No acknowledgments No retransmissions No ordering guarantees In short: fire and forget. Datagram vs Packet: What’s the Difference? The term "datagram" refers to a self-contained unit of data that carries all the information needed for delivery. A packet is a more general term. While all datagrams are packets, not all packets are datagrams. In the context of UDP, we refer to the data unit as a datagram because it’s transmitted without guaranteed delivery. Imagine sending a bunch of postcards through regular mail. Each one has a destination address, but there’s no way to know if it was delivered unless someone tells you. That’s UDP. UDP vs TCP: A Quick Comparison Why Use UDP? Despite its limitations, UDP has some powerful advantages: 1. Speed UDP is fast. Since it doesn’t establish a connection or manage reliability, it avoids delays associated with TCP handshakes and acknowledgments. 2. Low Overhead UDP has a minimal header size (just 8 bytes), making it more efficient for small messages. 3. No Connection State Since there’s no connection, UDP doesn’t require memory or tracking on either end, which makes it suitable for lightweight and scalable applications. 4. Real-Time Applications For applications like video calls, online games, and live streaming, speed trumps reliability. If a few packets are dropped, it's better to move on than wait for a retransmission. Common Use Cases for UDP DNS (Domain Name System): Quick request/response lookups DHCP (Dynamic Host Configuration Protocol): Assigning IP addresses VoIP (Voice over IP): Real-time audio Video Streaming: Especially when implemented via WebRTC Online Multiplayer Games: Low-latency actions Summary UDP may not guarantee delivery or ordering, but what it offers is speed, simplicity, and minimalism. It’s the go-to protocol when your application can tolerate some data loss but demands low latency. Understanding UDP is the first step in grasping how modern networking applications work. In our next post, we’ll go deeper into the protocol’s internals and explore its structure and limitations in more technical detail.

May 11, 2025 - 11:08

What is UDP? Understanding the “Unreliable” Transport Protocol

When you send a message over the internet—whether it’s a cat meme, a video stream, or a DNS lookup—it’s traveling through layers of protocols. Two of the most important transport-layer protocols in this stack are TCP and UDP. While TCP gets a lot of the spotlight thanks to its reliability and widespread use in web traffic, UDP (User Datagram Protocol) is the unsung hero behind many real-time and low-latency applications.

In this post, we’ll demystify what UDP is, how it works, and why developers choose it despite its nickname: the "Unreliable Datagram Protocol."

What is UDP?

UDP is one of the core protocols of the Internet Protocol (IP) suite. It was introduced in 1980 as a lightweight alternative to TCP. UDP operates on top of IP and is used to send short messages called datagrams.

The key difference? UDP doesn’t establish a connection before sending data. It just sends packets and hopes they arrive. This simplicity means:

No handshakes
No acknowledgments
No retransmissions
No ordering guarantees

In short: fire and forget.

Datagram vs Packet: What’s the Difference?

The term "datagram" refers to a self-contained unit of data that carries all the information needed for delivery. A packet is a more general term. While all datagrams are packets, not all packets are datagrams. In the context of UDP, we refer to the data unit as a datagram because it’s transmitted without guaranteed delivery.

Imagine sending a bunch of postcards through regular mail. Each one has a destination address, but there’s no way to know if it was delivered unless someone tells you. That’s UDP.

UDP vs TCP: A Quick Comparison

Why Use UDP?

Despite its limitations, UDP has some powerful advantages:

1. Speed
UDP is fast. Since it doesn’t establish a connection or manage reliability, it avoids delays associated with TCP handshakes and acknowledgments.

2. Low Overhead
UDP has a minimal header size (just 8 bytes), making it more efficient for small messages.

3. No Connection State
Since there’s no connection, UDP doesn’t require memory or tracking on either end, which makes it suitable for lightweight and scalable applications.

4. Real-Time Applications
For applications like video calls, online games, and live streaming, speed trumps reliability. If a few packets are dropped, it's better to move on than wait for a retransmission.

Common Use Cases for UDP

DNS (Domain Name System): Quick request/response lookups
DHCP (Dynamic Host Configuration Protocol): Assigning IP addresses
VoIP (Voice over IP): Real-time audio
Video Streaming: Especially when implemented via WebRTC
Online Multiplayer Games: Low-latency actions

Summary

UDP may not guarantee delivery or ordering, but what it offers is speed, simplicity, and minimalism. It’s the go-to protocol when your application can tolerate some data loss but demands low latency.

Understanding UDP is the first step in grasping how modern networking applications work. In our next post, we’ll go deeper into the protocol’s internals and explore its structure and limitations in more technical detail.