Introduction: The Postcard of the Internet

In the world of internet protocols, if TCP is the equivalent of a formal, tracked, and signed-for courier service, then the User Datagram Protocol (UDP) is the simple, no-frills postcard. You write your message, put an address on it, and drop it in the mailbox. You assume it will get there, but there is no confirmation of receipt, no guarantee it will not get lost, and no way of knowing if it will arrive before or after another postcard you sent at the same time.

This might sound flawed, but this simplicity is UDP-s greatest strength. UDP is a core member of the Internet Protocol Suite and operates at the Transport Layer, just like TCP. However, it serves a completely different purpose. While TCP goes to great lengths to ensure every single byte is delivered reliably and in order, UDP strips away all of that overhead. It provides a bare-bones mechanism to send messages, called datagrams, from one application to another.

UDP makes a deliberate trade-off: it sacrifices the reliability, ordering, and flow control of TCP in exchange for speed, low latency, and minimal overhead. For many modern internet applications, this is exactly the right choice. Applications that are sensitive to delay, such as video streaming or online gaming, often prefer the speed of UDP over the guarantees of TCP, choosing to handle any potential data loss themselves at the application layer. UDP is the protocol for when getting the data there fast is more important than guaranteeing that every single piece of data gets there perfectly.

Core Characteristics of UDP

UDP is defined by what it does not do. Its minimalist design is reflected in its core characteristics, which stand in stark contrast to those of TCP.

• Connectionless

  UDP is a connectionless protocol. Unlike TCP, there is no formal process for establishing a connection before data is sent. There is no three-way handshake. An application using UDP can simply create a datagram, add a destination address and port, and send it out onto the network. The first packet sent to a server is the data itself.

  The postcard analogy works perfectly here. You do not need to call the recipient first to confirm they are ready to receive a postcard; you just send it. This lack of a setup phase significantly reduces the initial latency of communication.

• Unreliable, Best-Effort Delivery

  This is the most important characteristic of UDP. It operates on a best-effort model. This means that UDP and the underlying IP network will try their best to deliver your datagram, but they offer absolutely no guarantees. UDP does not implement:

  • Acknowledgments: The receiver does not send any confirmation back to the sender that a datagram was received.
  • Retransmission: If a datagram is lost in transit, UDP will not automatically retransmit it. The data is simply gone.
  • Data Ordering: UDP datagrams are sent as independent entities. If you send datagram A followed by datagram B, the network might deliver B before A, or deliver both, or neither. UDP does nothing to reorder them at the destination.
• Low Overhead and High Speed

  The primary benefit of sacrificing reliability is minimal overhead. A TCP header is complex and is at least 20 bytes long. A UDP header is remarkably simple and has a fixed size of only 8 bytes. This means less control data needs to be sent with each piece of application data, resulting in higher efficiency.

  Furthermore, the absence of connection state, retransmission timers, acknowledgment tracking, and windowing buffers means that a system can send and process UDP datagrams with much less computational effort and memory, leading to higher speeds and lower latency.

• No Flow or Congestion Control

  UDP does not have any built-in mechanisms for flow control or congestion control. An application using UDP can send data as fast as it wants, regardless of the receiver-s ability to process it or the overall congestion on the network. This can be both a benefit (for applications that need to maintain a constant sending rate) and a danger (as a misbehaving UDP application could flood the network and cause problems for other users). For this reason, applications built on UDP must often implement their own control mechanisms.

The UDP Header: A Model of Simplicity

The minimalist philosophy of UDP is perfectly captured in its header format. It contains only four fields, each 16 bits (2 bytes) long, for a total fixed header size of 8 bytes.

Detailed Field Descriptions

When is UDP the Right Choice? Applications and Use Cases

UDP-s design makes it ideal for applications where timeliness is more critical than perfect reliability, or where the application itself prefers to manage reliability.

Can UDP Be Made Reliable? The Application-Layer Approach

The unreliability of UDP is not a verdict; it is a choice. UDP hands the responsibility for reliability over to the application layer. This means developers can, and often do, build their own reliability mechanisms on top of UDP-s fast datagram service.

An application can implement its own custom system of sequence numbers, acknowledgments, and retransmission timers. This provides a great deal of flexibility. For example, a game might need to reliably transmit chat messages while unreliably transmitting player positions. By building on UDP, the developer can create a hybrid system, ensuring chat messages are retransmitted if lost, while position updates are not. This selective reliability, tailored to the application-s specific needs, is impossible with the one-size-fits-all approach of TCP.

This philosophy of using UDP as a base and building smarter protocols on top is the future of internet transport. The most prominent example is QUIC (Quick UDP Internet Connections), the protocol that underpins HTTP/3. QUIC runs over UDP and re-implements many of TCP-s features, like reliability and congestion control, but in a more efficient and flexible way that avoids many of TCP-s historical problems.