UDP: What is the User Datagram Protocol?

The com­mu­nic­a­tion of systems in local home and corporate networks as well as public networks such as the internet is based by default on the internet protocol family. The most well-known component of this protocol stack is un­doubtedly the Internet Protocol (IP), which is not only re­spons­ible for ad­dress­ing and frag­ment­ing data packets, but also defines how in­form­a­tion about source and des­tin­a­tion is described. However, the trans­mis­sion of data is usually handled by the con­nec­tion-ori­ent­ated Trans­mis­sion Control Protocol (TCP), which is why networks are often referred to as TCP/IP networks. Because TCP provides security but also delays trans­mis­sion, David Patrick Reed published his User Datagram Protocol (UDP) concept in 1980 as a simpler and faster al­tern­at­ive to the standard protocol.

The User Datagram Protocol, or UDP for short, is a protocol that allows datagrams to be sent without con­nec­tion in IP-based networks. To achieve the desired services on the target hosts, it uses ports that are listed as one of the core com­pon­ents in the UDP header. Like many other network protocols, UDP belongs to the internet protocol family, where it is clas­si­fied as a mediator between the network layer and the ap­plic­a­tion layer at the transport level.

By using the User Datagram Protocol, an ap­plic­a­tion can send in­form­a­tion very quickly, since neither a con­nec­tion to the addressee has to be es­tab­lished nor do you have to wait for an answer. However, there is no guarantee that packets will arrive complete and in the same order in which they were sent. In addition, the protocol does not provide its own pro­tec­tion against ma­nip­u­la­tion or access by third parties. However, faulty packets can be detected by an optional usable checksum (mandatory in com­bin­a­tion with IPv6).

To un­der­stand how packet trans­mis­sion works with the protocol in detail, it is useful to take a closer look at the prop­er­ties of the User Datagram Protocol.

1. UDP is con­nec­tion­less: Data transport via UDP is char­ac­ter­ised by the fact that it takes place without an existing con­nec­tion between addressee and recipient. The re­spect­ive packets are then sent to the preferred IP address, spe­cify­ing the target port, without the computer behind them having to respond. However, if packets are also to be returned to the recipient, the UDP header can op­tion­ally also contain the source port.
2. UDP uses ports: Like TCP, UDP uses ports so that the packets are trans­ferred to the correct sub­sequent protocols or the desired ap­plic­a­tions on the target system. The ports are defined by numbers according to the proven pattern, with numbers between 0 and 1023 assigned to fixed services.
3. UDP enables fast, delay-free com­mu­nic­a­tion: The transport protocol is suitable for fast data trans­mis­sion due to the lack of con­nec­tion setup. This also results from the fact that the loss of in­di­vidu­al packets only affects the quality of the trans­mis­sion. With TCP con­nec­tions, on the other hand, lost packets are auto­mat­ic­ally re-requested, causing the entire trans­mis­sion process to come to a stand­still.
4. UDP does not guarantee the security and integrity of the data: The absence of mutual au­then­tic­a­tion between addressee and recipient ensures the excellent trans­mis­sion speed of UDP – however, the protocol can neither guarantee the com­plete­ness nor the security of the data packets. The correct sequence of the sent packets is also not guar­an­teed. For this reason, the services that use UDP must provide their own measures for cor­rec­tion or pro­tec­tion.

As is typical for protocols, UDP packets consist of a header and the actual user data. The UDP header contains all the in­form­a­tion required for data trans­mis­sion using the transport protocol, and makes a UDP packet iden­ti­fi­able as such. Divided into two 32-bit blocks with four different data fields, the structure is as follows:

The first 16 bits of the header area reveal the source port via which the re­spect­ive data packet is sent. The receiver needs this in­form­a­tion to be able to respond to the packet. Since UDP is con­nec­tion­less and there is no exchange between addressee and receiver, this field is optional. Therefore, the value "0" is usually set here.

In the next field, the target port and thus the service to be accessed is specified. In contrast to the source port, this in­form­a­tion is mandatory, otherwise the datagram cannot be assigned correctly.

The length field defines the length of the datagram. This consists of the length of the header (8 bytes) and the size of the user data (the­or­et­ic­al maximum: 65,535 bytes). When using IPv4, the actual limit for the user data is 65,507 bytes – after deducting IP and UDP headers. In IPv6, packets (so-called jum­bo­grams) that exceed the maximum are also possible. According to RFC 2675, the value of the length field is set to "0" in such a case.

The UDP header is ter­min­ated by the checksum, which is used for error detection during trans­mis­sion. In this way, any ma­nip­u­la­tions of the trans­mit­ted data can be detected – however, cor­res­pond­ing packets are discarded without a new request. To generate the sum, parts of the

• UDP header,
• the user data,
• as well as the so-called pseudo-header (contains IP header in­form­a­tion)

are included.

The checksum is optional in IPv4, but is used by most ap­plic­a­tions by default. If you omit it, this field will also take the value "0." If UDP is used in com­bin­a­tion with IPv6, the checksum is mandatory.

The User Datagram Protocol has a min­im­al­ist­ic structure and missing mech­an­isms in order to guarantee a complete, suc­cess­ful trans­mis­sion, but cannot be used as a universal transport protocol. Rather, it was designed from the outset for ap­plic­a­tions that do not (yet) require a reliable trans­mis­sion service. The field of ap­plic­a­tion of UDP is con­sequently limited, but nev­er­the­less un­der­lines the enormous value of the protocol, as the following ap­plic­a­tion classes for UDP prove:

• "Best-effort delivery" ap­plic­a­tions: The classic de­ploy­ment scenario for UDP is ap­plic­a­tions that are based on "data delivery to the best of our ability." Such programs, which use the User Datagram Protocol as a "best effort" service, transmit in­form­a­tion un­re­li­ably because they are used to repeating this in­form­a­tion. Examples are ap­plic­a­tions that transmit measured values or re­peatedly execute the same work orders.
• Light­weight ap­plic­a­tions: The low transport protocol overload provides optimal support for ap­plic­a­tions that are very simple in design. In com­bin­a­tion with elim­in­at­ing the need to establish a con­nec­tion, these programs benefit from par­tic­u­larly high per­form­ance when pro­cessing and for­ward­ing data packets in networks.
• Ap­plic­a­tions with their own mech­an­isms for reliable trans­mis­sion: UDP can also be in­ter­est­ing for ap­plic­a­tions that are actually dependent on reliable in­form­a­tion exchange, but should have their own mech­an­isms for answering packets. The advantage of services like these is that they are not bound to fixed patterns in order to guarantee the com­plete­ness and cor­rect­ness of the data packets sent. You can decide for yourself how and when to respond to incorrect or unsorted in­form­a­tion.
• Multicast ap­plic­a­tions: While reliable transport protocols such as TCP are limited to the use of end-to-end com­mu­nic­a­tion, UDP also supports IP multicast con­nec­tions. If an ap­plic­a­tion is to be able to send IP packets ef­fi­ciently and quickly to many re­cip­i­ents at the same time, UDP creates a suitable basis.
• Real-time ap­plic­a­tions: UDP is also suitable as a transport protocol for services that work with real-time re­quire­ments – such as audio or video trans­mis­sions. They must be able to largely control the trans­mis­sion, reception, and re­pro­duc­tion of data streams them­selves, which is easily possible with con­nec­tion­less UDP trans­mis­sion.