User Datagram Protocol

From Citizendium
Jump to navigation Jump to search
This article is developing and not approved.
Main Article
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
This editable Main Article is under development and subject to a disclaimer.

The User Datagram Protocol is one of the two original end-to-end protocols of the Internet; it has lower overhead than the Transmission Control Protocol, but also provides fewer services.[1] When used for the correct application, UDP is quite efficient.

As opposed to TCP, UDP does not attempt to maintain a connection between endpoints. Each chunk of data it sends, called a segment, is treated independently, rather than as a segment. UDP does not attempt to keep these segments (or the packets making them up) in order, or correct errors if errors are present in a received segment. It does guarantee that received packets are free of error. If errors are present, the segment is discarded. Typically, the relatively weak error-checking mechanism of UDP (and also TCP) is a double-check on the much stronger error detection of the data link protocols used on each transmission medium the packet traverses.[2]

Segment description

A segment is very simple, with a header followed by data. The header is 8 bytes long, with four 2-byte fields. Two of the fields, source port and destination port, identify a specific service or process associated with the source or destination address. For example, the well-known port for the Domain Name System is 53. There is a two-byte length field, which includes the header, so the minimum value is 8 and the maximum 65535.

The remaining field, checksum, is more complex. It is confusing because it is not computed on the segment, but on a pseudo-header that includes the source and destination IP addresses, protocol ID, and the UDP length. from the packet in which the segment is being sent. This technique, the same as in TCP, protects against segments that are misrouted with bad address information.


Use with applications that can use damaged data

Some applications do not need a guarantee that received data is error-free or not delivered at all, and, for this, Lightweight UDP (UDPlite) was developed. [3] There are at least three classes of application that prefer errored data to no data:

  • Voice and data applications that have codecs that can compensate better for errors in a packet payload tan for losing the entire packet.
  • The standard behavior for IP is that media carrying IP must[4] use a strong data integrity check. If, however, a particular data link layer technology may, if requested, not discard errored frames. This is a feature of some digital radio links used in cellular telephony. In other case, if a link technology with a high expectation of errors, and is informed that some parts of the packet are more error sensitive than others, the link mechanism may command the underlying physical link to use technologies to reduce the probability that those bytes will be in error (e.g., with unequal Forward Error Correction).
  • Error-tolerant applications should not be protected, by lower layers, from errors that they can tolerate. UDP is best because it imposes the least overhead. In Internet Protocol version 4 (IPv4), the UDP checksum covers either the entire packet or nothing at all, but this is less critical because IPv4 has a packet header-only checksum. Internet Protocol version 6 (IPv6), as opposed to IPv4, does not have a packet-level checksum to protect the packet header. The end-to-end protocol must provide that protection for IPv6.

For such applications, critical information, such as packet and segment headers, need to be protected, but not the payload. UDP-Lite allows the transmitter to specify what parts of the segment are, and are not, covered by the checksum. Only errors in the sensitive part, covered by the checksum, will be discarded at the receiver. If all of the segment is defined as sensitive, UDP-Lite behaves in the same way as UDP.


  1. Postel, J. (August 1980), User Datagram Protocol, Internet Engineering Task Force, RFC0768
  2. Karn, P. et al. (July 2004), User Datagram Protocol, Internet Engineering Task Force, RFC3819
  3. Larzon, L-A. et al. (July 2004), The Lightweight User Datagram Protocol (UDP-Lite), Internet Engineering Task Force, RFC3828
  4. In IETF documents, "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" have specific meanings, defined in RFC2119.