User Datagram Protocol

User Datagram Protocol

Protocol stack
Abbreviation	UDP
Developer	David P. Reed
Introduction	1980;46 years ago (1980)
Influenced	QUIC, UDP-Lite
OSI layer	Transport layer (4)
IP number	17
RFCs	768, 9868

UDP pseudo-header for checksum computation (IPv6)

Internet protocol suite
Application layer
BGP DHCP (v6) DNS FTP HTTP (HTTP/3) HTTPS IMAP IPP IRC LDAP MGCP MQTT NNTP NTP OSPF POP PTP ONC/RPC RTP RTSP RIP SIP SMTP SNMP SSH Telnet TLS/SSL XMPP more...
Transport layer
TCP UDP DCCP SCTP RSVP QUIC more...
Internet layer
IP v4 v6 ICMP (v6) NDP ECN L4S IGMP IPsec more...
Link layer
ARP Tunnels PPP MAC more...
Attributes edit UDP is a simple message-oriented transport layer protocol that is documented in Source Port: 16 bits This field identifies the sender's port, when used, and should be assumed to be the port to reply to if needed. If the source host is the client, the port number is likely to be an ephemeral port. If the source host is the server, the port number is likely to be a well-known port number from 0 to 1023. "}},"i":0}}]}'>Destination Port: 16 bits This field identifies the receiver's port and is required. Similar to the source port number, if the client is the destination host then the port number will likely be an ephemeral port number, and if the destination host is the server, then the port number will likely be a well-known port number. {{cite book |last=Stevens |first=W. Richard |year=1994 |title=TCP/IP Illustrated: The protocols |volume=1 |edition=2 |publisher=Addison-Wesley |isbn=978-0-20-163346-7}}</ref>\n: Using IPv6 [[jumbogram]]s it is possible to have UDP datagrams of size greater than 65,535 bytes. The length field is set to zero if the length of the UDP header plus UDP data is greater than 65,535.{{Ref RFC|2675}}"}},"i":0}}]}'>Length: 16 bits This field specifies the length of the UDP datagram (the header fields and Data field) in octets. The minimum length is 8 bytes, the length of the header. The field size sets a theoretical limit of 65,535 bytes (8-byte header + 65,527 bytes of data) for a UDP datagram. However, the actual limit for the data length, which is imposed by the underlying IPv4 protocol, is 65,507 bytes (65,535 bytes − 8-byte UDP header − 20-byte IP header). Using IPv6 jumbograms it is possible to have UDP datagrams of size greater than 65,535 bytes. The length field is set to zero if the length of the UDP header plus UDP data is greater than 65,535. RFC 768, and efficient calculation is discussed in Source Address: 32 bits The source address from the IPv4 header. Protocol: 8 bits The protocol value for UDP: 17 (or 0x11).
Offset	Octet	0								1								2								3
Octet	Bit	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Source address
4	32
8	64
12	96
16	128	Destination address
20	160
24	192
28	224
32	256	UDP length
36	288	Zeroes (0)																								Next Header (17)
40	320	Source port																Destination port
44	352	Length																Checksum
48	384	Data
52	416
⋮	⋮

The checksum is computed over the following fields:

UDP length: 32 bits

The length of the UDP header and data (measured in octets).

17.

Lacking reliability, UDP applications may encounter some packet loss, reordering, errors or duplication. If using UDP, the end-user applications must provide any necessary handshaking, such as real-time confirmation that the message has been received. Certain applications (e.g., TFTP) may incorporate rudimentary reliability mechanisms at the application layer as required. For applications demanding a high degree of reliability, an alternative protocol such as the Transmission Control Protocol may be used instead.

Most often, UDP applications do not employ reliability mechanisms and may even be hindered by them. Streaming media, real-time multiplayer games and voice over IP (VoIP) are typical applications that leverage UDP. In these particular applications, loss of packets is not usually a fatal problem. In VoIP, for example, latency and jitter are the primary concerns. The use of TCP would cause jitter if any packets were lost, as TCP does not provide subsequent data to the application while it is requesting a re-send of the missing data.

Numerous key Internet applications use UDP, including: the Domain Name System (DNS), the Simple Network Management Protocol (SNMP), the Routing Information Protocol (RIP) and the Dynamic Host Configuration Protocol (DHCP).

Voice and video traffic is generally transmitted using UDP. Real-time video and audio streaming protocols are designed to handle the occasional lost packets, so only slight degradation in quality occurs, compared to the large delays that would occur if lost packets were retransmitted. Because both TCP and UDP run over the same network, in the mid-2000s a few businesses found that an increase in UDP traffic from these real-time applications slightly hindered the performance of applications using TCP such as point of sale, accounting, and database systems (when TCP detects packet loss, it will throttle back its data rate usage).

Some VPN systems, such as OpenVPN, support operation over UDP and provide application-layer error checking as well as mechanisms to enhance transmission reliability. WireGuard uses UDP and performs error checking, but does not provide any reliability guarantees; reliability is delegated to upper-layer protocols within the tunnel or to end applications.

QUIC is a transport protocol built on top of UDP. QUIC provides a reliable and secure connection. HTTP/3 uses QUIC as opposed to earlier versions of HTTPS which use a combination of TCP and TLS to ensure reliability and security respectively. This means that HTTP/3 uses a single handshake to set up a connection, rather than having two separate handshakes for TCP and TLS, meaning the overall time to establish a connection is reduced.

Transmission Control Protocol is a connection-oriented protocol and requires handshaking to set up end-to-end communications. Once a connection is set up, user data may be sent bi-directionally over the connection.

• Reliable – TCP manages message acknowledgment, retransmission and timeouts. Multiple attempts to deliver the message are made. If data gets lost along the way, it will be resent. In TCP, there's either no missing data or, in case of multiple timeouts, the connection is dropped.
• Ordered – If two messages are sent over a connection in sequence, the first message will reach the receiving application first. When data segments arrive in the wrong order, TCP buffers the out-of-order data until all data can be properly re-ordered and delivered to the application.
• Heavyweight – TCP requires three packets to set up a socket connection before any user data can be sent. TCP handles reliability and congestion control.
• Streaming – Data is read as a byte stream; no distinguishing indications are transmitted to signal message (segment) boundaries.

User Datagram Protocol is a simpler message-based connectionless protocol. Connectionless protocols do not set up a dedicated end-to-end connection. Communication is achieved by transmitting information in one direction from source to destination without verifying the readiness or state of the receiver.

• Unreliable – When a UDP message is sent, it cannot be known if it will reach its destination; it could get lost along the way. There is no concept of acknowledgment, retransmission, or timeout.
• Not ordered – If two messages are sent to the same recipient, the order in which they arrive cannot be guaranteed.
• Lightweight – There is no ordering of messages, no tracking connections, etc. It is a very simple transport layer designed on top of IP.
• Datagrams – Packets are sent individually and are checked for integrity on arrival. Packets have definite boundaries, which are honored upon receipt; a read operation at the receiver socket will yield an entire message as it was originally sent.
• No congestion control – UDP itself does not avoid congestion. Congestion control measures must be implemented at the application level or in the network.
• Broadcasts – being connectionless, UDP can broadcast - sent packets can be addressed to be receivable by all devices on the subnet.
• Multicast – a multicast mode of operation is supported whereby a single datagram packet can be automatically routed without duplication to a group of subscribers.

• RFC 2675 – IPv6 Jumbograms
• 1. ↑ Kurose, J. F.; Ross, K. W. (2010). Computer Networking: A Top-Down Approach (5th ed.). Boston, MA: Pearson Education. ISBN 978-0-13-136548-3.
  2. ↑ Clark, M.P. (2003). Data Networks IP and the Internet, 1st ed. West Sussex, England: John Wiley & Sons Ltd.
  3. ↑ Stevens, W. Richard (1994). TCP/IP Illustrated: The protocols. Vol. 1 (2 ed.). Addison-Wesley. ISBN 978-0-20-163346-7.
  4. ↑ S. Deering; R. Hinden (July 2017). Internet Protocol, Version 6 (IPv6) Specification. Internet Engineering Task Force. doi:10.17487/RFC8200. STD 86.RFC 8200. Internet Standard 86. Obsoletes Internet Protocol, Version 6 (IPv6) Specification. IETF. p. 23. doi:10.17487/RFC8085. RFC 8085.
  5. ↑