User Datagram Protocol

from Wikipedia, the free encyclopedia
UDP (User Datagram Protocol)
Family: Internet protocol family
Operation area: Connectionless transmission
of data over the Internet
UDP in the TCP / IP protocol stack :
application DNS DHCP ...
transport UDP
Internet IP ( IPv4 , IPv6 )
Network access Ethernet Token
bus 		Token
ring 		FDDI ...
Standards: RFC 768 ( 1980 )

The User Datagram Protocol , or UDP for short , is a minimal, connectionless network protocol that belongs to the transport layer of the Internet protocol family. UDP enables applications to send datagrams in IP-based computer networks .

The development of UDP began in 1977 when a simpler protocol was required for the transmission of speech than the previous connection-oriented TCP . A protocol was required that was only responsible for addressing without securing data transmission, as this would lead to delays in voice transmission.

functionality

UDP uses ports to allow sent data to the correct program on the target computer. To do this, each datagram contains the port number of the service that is to receive the data. This extension of the Internet Protocol host-to-host transmission to process-to-process transmission is known as application multiplexing and demultiplexing.

In addition, UDP offers the option of an integrity check by sending a checksum . This means that incorrectly transmitted datagrams can be recognized and discarded.

properties

UDP is a connectionless , non-reliable and unsecured as well as unprotected transmission protocol. This means that there is no guarantee that a packet that has been sent once will arrive, that packets will arrive in the same order in which they were sent, or that a packet will only reach the recipient once. There is also no guarantee that the data will arrive unadulterated or inaccessible to third parties at the recipient. An application that uses UDP must therefore be insensitive to lost and unsorted packets or provide appropriate corrective measures and, if necessary, security measures.

Since a connection does not have to be established before the start of the transfer, one or both partners can start exchanging data more quickly. This is particularly important in applications where only small amounts of data need to be exchanged. Simple question-and-answer protocols such as DNS (the Domain Name System ) mainly use UDP for name resolution in order to keep the network load low and thus increase the data throughput. A three-way handshake as with TCP (the Transmission Control Protocol ) for establishing the connection would generate unnecessary overhead in this case .

In addition, the unsecured transmission also offers the advantage of low transmission delay fluctuations: If a packet is lost in a TCP connection, it is automatically requested again. This takes time and the transmission time can therefore fluctuate, which is bad for multimedia applications. For VoIP z. For example, there would be sudden dropouts or the playback buffers would have to be made larger. In the case of connectionless communication services, on the other hand, lost packets do not stop the entire transmission, but only reduce the quality.

Theoretically, the maximum size of a UDP datagram is 65,535 bytes, since the length field of the UDP header is 16 bits long and the largest number that can be represented with 16 bits is 65,535 (= 2 16 −1). However, such large segments are transmitted fragmented by IP. In practice, the maximum possible length of a UDP datagram is subject to further restrictions .

IP deletes packets in the event of transmission errors or overload. Datagrams can therefore be missing. UDP does not offer any detection or correction mechanisms for this, such as TCP. In the case of several possible routes to the destination, IP can choose new routes if necessary. This means that in rare cases it is possible that data sent later overtake earlier sent data. In addition, a data packet sent once can arrive at the recipient several times.

UDP datagram

In addition to the user data to be transmitted, other information is also sent, which is always at the beginning of a UDP message, in the so-called header . The UDP header consists of four data fields, each of which is 16 bits in size:

bit 0 15th 16 31
Source port Destination port
length Checksum
Data
UDP datagram header format
Source port
specifies the port number of the sending process. This information is required so that the recipient can reply to the package. Since UDP is connectionless, the source port is optional and can be set to the value "0" (in the event that no response packets are expected and only packets are to be sent to the recipient).
Destination port
indicates which process should receive the packet.
Längenfeld
specifies the length of the datagram, consisting of the data and the header, in octets . The smallest possible value is 8 octets (or bytes). The length field defines a theoretical upper limit of 2 16 −1 = 65,535 bytes (8 byte header + 65,527 bytes of user data). Due to the underlying IP protocol, the actually available length of the user data is limited to 65,507 bytes (65,535 - 8 byte UDP header - 20 byte IP header) when using IPv4 and 65,527 bytes when using IPv6 .
Checksum field
a 16-bit checksum can also be sent. The checksum is formed using the so-called pseudo header , the UDP header and the data. The checksum is optional, but is almost always used in practice, if not, it is set to "0".
Data field
it contains the actual payload, also known as the payload . The field is optional and can theoretically be completely absent, which actually never happens in practice. The data field always consists of an even number of octets. Octets that remain free at the end are padded with zeros.

Pseudo headers

The Internet Protocol (IP) is provided for the transmission of the UDP packet . In front of the UDP packet, this protocol places another header in which the data required by IP are located:

To generate the UDP checksum, parts of this IP header are transferred to a so-called "pseudo header". It is only used to generate the checksum and is not transmitted.

IPv4

With IPv4, the pseudo header has a size of 12 octets (96 bits) and is made up of the source IP address (32 bits), destination IP address (32 bits), 8 bits of empty field, and 8 bits of protocol ID (UDP has ID 17 ) and the length of the UDP datagram (16 bits):

bit 0 32 64 72 80 96
Source IP address Destination IP address 00000000 Protocol ID UDP datagram length
IPv4 pseudo header

IPv6

With IPv6 , the pseudo header has a size of 40 octets (320 bits). It is composed as follows:

bit 0 128 256 288 312 320
Source IP address Destination IP address Upper-Layer Packet Length 0
(24 bit) 		Next header
IPv6 pseudo header

Calculation of the checksum

The sender's checksum is calculated using the following algorithm:

  1. Set the checksum field in the UDP header to 0000 0000 0000 0000.
  2. Generate an unsigned 32-bit number for the checksum, initialize it with zeros.
  3. Combine directly neighboring bytes of the UDP packet into 16-bit blocks. If the last block has less than 16 bits, then fill it with zeros from the end until it has 16 bits.
  4. Save the result of adding all 16-bit blocks with carry in the checksum.
  5. Combine directly adjacent bytes of the pseudo header into 16-bit blocks.
  6. Save the result of adding these 16-bit blocks and the previous checksum with carry in the checksum.
  7. Combine directly neighboring bytes of the checksum into two 16-bit blocks, add them and save the result with carry in the checksum until there is no more carry in the addition.
  8. The most significant 16 bits of the 32-bit checksum are now zeros. The less significant bits are the actual checksum; save this as an unsigned 16-bit number.
  9. If this 16-bit number is not all ones, then store its one's complement in the UDP header (both 1111 1111 1111 1111 and its one's complement, 0000 0000 0000 0000, symbolize the number 0). In IPv4 UDP, 0000 0000 0000 0000 is also used to signal that no checksum has been calculated. IPv6 UDP packets with the checksum 0000 0000 0000 0000 are invalid ( RFC 6935 ).

The recipient first checks whether the checksum field of the received packet only consists of zeros. If so, it can evaluate the packet as correctly received, since no checksum is available. If not, it applies the algorithm described above to the received packet and the associated pseudo-header, omits the last step and adds the self-calculated checksum to the checksum received in the checksum field, which corresponds to a subtraction due to the one's complement representation. If the receiver receives 0 as the result of the addition (or subtraction), it evaluates the received data as the same as the sent data.

UDP-Lite

The Lightweight User Datagram Protocol (UDP-Lite) according to RFC 3828 is a variation of UDP, especially for the transmission of data where there is little delay, but smaller errors can be tolerated. This is the case, for example, with live audio and video transmissions , which often use UDP as the transport protocol. If a bit in a UDP data packet is faulty, all data in the packet, i.e. H. up to several thousand bits, discarded. If, on the other hand, the packet with the faulty bit were used, the error would be inaudible or invisible , depending on the codec . By using UDP-Lite, the checking of certain parts of the data packets by the lower layers should be suppressed, effectively only for UDP-Lite packets. At the Ethernet level, this affects the CRC check of the packets.

UDP-Lite is compatible with UDP, but interprets the length field as the length over which the checksum is calculated ( checksum coverage ). A normal UDP packet always corresponds to the specifications of UDP-Lite. Conversely, this is not necessarily the case, as UDP-Lite defines a higher degree of freedom. The length of a UDP or UDP-Lite packet can be calculated using the information from the Internet Protocol Layer ; the IP length is the sum of the IP header size and the UDP packet size. If the IP header in UDP-Lite is longer than in the length field of the UDP (-Lite) header, the packet contains additional, unchecked data. For example, a length field of eight means that the checksum is only calculated using the header. With the value zero, the checksum is calculated over the entire packet. The values ​​1,…, 7 are not allowed, i. H. the UDP-Lite header is always included in the checksum. The limitation of the maximum packet size from UDP (65,535 bytes) does not apply. In this case, the checksum can be calculated either over the entire packet or over the first 65,535 bytes at most.

Specifications

  • RFC 768 User Datagram Protocol
  • RFC 3828 The Lightweight User Datagram Protocol (UDP-Lite)

See also

Web links

Individual evidence

  1. ↑ RFC 5405 - Unicast UDP Usage Guidelines.
  2. ↑ RFC 768 - User Datagram Protocol. (English, PDF: tools.ietf.org ).