The User Datagram Protocol (UDP) is a transport layer protocol defined for use with the IP network layer protocol. It is defined by RFC 768 written by John Postel. It provides a best-effort datagram service to an End System (IP host).
The service provided by UDP is an unreliable service that provides no guarantees for delivery and no protection from duplication (e.g. if this arises due to software errors within a router). The simplicity of UDP reduces the overhead from using the protocol and the services may be adequate in many cases.
UDP provides a minimal, unreliable, best-effort, message-passing transport to applications and upper-layer protocols. Compared to other transport protocols.
UDP does not establish end-to-end connections between communicating end systems. UDP communication consequently does not incur connection establishment and teardown overheads and there is minimal associated end system state. Because of these characteristics, UDP can offer a very efficient communication transport to some applications, but has no inherent congestion control or reliability.
A second characteristic of UDP is that it provides no inherent On many platforms, applications can send UDP datagrams at the line rate of the link interface, which is often much greater than the available path capacity, and doing so would contribute to congestion along the path, applications therefore need to be designed responsibly [RFC 4505].
One increasingly popular use of UDP is as a tunneling protocol, where a tunnel endpoint encapsulates the packets of another protocol inside UDP datagrams and transmits them to another tunnel endpoint, which decapsulates the UDP datagrams and forwards the original packets contained in the payload. Tunnels establish virtual links that appear to directly connect locations that are distant in the physical Internet topology, and can be used to create virtual (private) networks. Using UDP as a tunneling protocol is attractive when the payload protocol is not supported by middleboxes that may exist along the path, because many middleboxes support UDP transmissions.
UDP does not provide any communications security. Applications that need to protect their communications against eavesdropping, tampering, or message forgery therefore need to separately provide security services using additional protocol mechanisms.
A computer may send UDP packets without first establishing a connection to the recipient. A UDP datagram is carried in a single IP packet and is hence limited to a maximum payload of 65,507 bytes for IPv4 and 65,527 bytes for IPv6. The transmission of large IP packets usually requires IP fragmentation. Fragmentation decreases communication reliability and efficiency and should theerfore be avoided.
To transmit a UDP datagram, a computer completes the appropriate fields in the UDP header and forwards the data together with the header for transmission by the IP network layer.
The UDP protocol header consists of 8 bytes of Protocol Control Information (PCI)
The UDP header consists of four fields each of 2 bytes in length:
Like for other transport protocols, the UDP header and data are not processed by Intermediate Systems (IS) in the network (e.g. routers), and are delivered to the final destination in the same form as originally transmitted.
At the final destination, the UDP protocol layer receives packets from the IP network layer. These are checked using the checksum (when >0, this checks correct end-to-end operation of the network service) and all invalid PDUs are discarded. UDP does not make any provision for error reporting if the packets are not delivered. Valid data are passed to the appropriate upper layer applictaion protocol identified by the source and destination port numbers.
UDP also may be used for multicast and broadcast, allowing senders to transmit to multiple receivers.
Application designers are generally aware that UDP does not provide any reliability, e.g., it does not retransmit any lost packets. Often, this is a main reason to consider UDP as a transport. Applications that do require reliable message delivery therefore need to implement appropriate protocol mechanisms in their applications (e.g. tftp).
UDP's best effort service does not protect against datagram duplication, i.e., an application may receive multiple copies of the same UDP datagram. Application designers therefore need to verify that their application gracefully handles datagram duplication and may need to implement mechanisms to detect duplicates.
The Internet may also significantly delay some packets with respect to others, e.g., due to routing transients, intermittent connectivity, or mobility. This can cause reordering, where UDP datagrams arrive at the receiver in an order different from the transmission order. Applications that require ordered delivery must restore datagram ordering themselves.
The burdon of needing to code all these protocol mechanims can be avoided by using TCP!
Generally, clients set the source port number to a unique number that they choose themselves - usually based on the program that started the connection.
[RFC4505] provides guidance on how to use UDP.
A User Datagram Protocol (UDP) packet containing 1460B of broadcast UDP payload data is transmitted over a 10 Mbps Ethernet LAN. What is the size of this frame went sent over a 100BT Ethernet LAN?
This packet has the following headers:
IFG (ignored).
Preamble and SFD (8B)
MAC Header (14B)
IP Packet header (20B - assuming no options)
UDP Header (8B)
UDP Payload (1460B)
CRC-32 (4B)
Total =8+12+20+8+1460+4 =1514B
The main purpose of the UDP Checksum is to detect problems that may arise within Intermediate Systems (where there is no CRC on the data). While the packet is being processed by the router the packet data is protected by the CRC. Router processing errors may otherwise pass undetected.
See also:
Standards Documents:
J. Postel. User Datagram Protocol, RFC 768.
R.T. Braden, D.A. Borman, C. Partridge, Computing the Internet Checksum, RFC 1071
L. Eggert, G. Fairhurst, Unicast UDP Usage Guidelines for Application Designers, RFC4505
List of Assigned UDP Port Numbers
Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.