UDP: User Datagram Protocol
The simplest transport protocol: connectionless, fast, and minimal overhead
Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.
@misc{rfc768,
series = {Request for Comments},
number = 768,
howpublished = {RFC 768},
publisher = {RFC Editor},
doi = {10.17487/RFC0768},
url = {https://www.rfc-editor.org/info/rfc768},
author = {J. Postel},
title = {{User Datagram Protocol}},
pagetotal = 3,
year = 1980,
month = aug,
} RFC text
Contents
RFC 768 J. Postel
ISI
28 August 1980
User Datagram Protocol
----------------------
Introduction
------------
This User Datagram Protocol (UDP) is defined to make available a
datagram mode of packet-switched computer communication in the
environment of an interconnected set of computer networks. This
protocol assumes that the Internet Protocol (IP) [1] is used as the
underlying protocol.
This protocol provides a procedure for application programs to send
messages to other programs with a minimum of protocol mechanism. The
protocol is transaction oriented, and delivery and duplicate protection
are not guaranteed. Applications requiring ordered reliable delivery of
streams of data should use the Transmission Control Protocol (TCP) [2].
Format
------
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| | |
| Length | Checksum |
+--------+--------+--------+--------+
|
| data octets ...
+---------------- ...
User Datagram Header Format
Fields
------
Source Port is an optional field, when meaningful, it indicates the port
of the sending process, and may be assumed to be the port to which a
reply should be addressed in the absence of any other information. If
not used, a value of zero is inserted.
28 Aug 1980
User Datagram Protocol RFC 768
Fields
Destination Port has a meaning within the context of a particular
internet destination address.
Length is the length in octets of this user datagram including this
header and the data. (This means the minimum value of the length is
eight.)
Checksum is the 16-bit one's complement of the one's complement sum of a
pseudo header of information from the IP header, the UDP header, and the
data, padded with zero octets at the end (if necessary) to make a
multiple of two octets.
The pseudo header conceptually prefixed to the UDP header contains the
source address, the destination address, the protocol, and the UDP
length. This information gives protection against misrouted datagrams.
This checksum procedure is the same as is used in TCP.
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| source address |
+--------+--------+--------+--------+
| destination address |
+--------+--------+--------+--------+
| zero |protocol| UDP length |
+--------+--------+--------+--------+
If the computed checksum is zero, it is transmitted as all ones (the
equivalent in one's complement arithmetic). An all zero transmitted
checksum value means that the transmitter generated no checksum (for
debugging or for higher level protocols that don't care).
User Interface
--------------
A user interface should allow
the creation of new receive ports,
receive operations on the receive ports that return the data octets
and an indication of source port and source address,
and an operation that allows a datagram to be sent, specifying the
data, source and destination ports and addresses to be sent.
28 Aug 1980
RFC 768 User Datagram Protocol
IP Interface
IP Interface
-------------
The UDP module must be able to determine the source and destination
internet addresses and the protocol field from the internet header. One
possible UDP/IP interface would return the whole internet datagram
including all of the internet header in response to a receive operation.
Such an interface would also allow the UDP to pass a full internet
datagram complete with header to the IP to send. The IP would verify
certain fields for consistency and compute the internet header checksum.
Protocol Application
--------------------
The major uses of this protocol is the Internet Name Server [3], and the
Trivial File Transfer [4].
Protocol Number
---------------
This is protocol 17 (21 octal) when used in the Internet Protocol.
Other protocol numbers are listed in [5].
References
----------
[1] Postel, J., "Internet Protocol," RFC 760, USC/Information
Sciences Institute, January 1980.
[2] Postel, J., "Transmission Control Protocol," RFC 761,
USC/Information Sciences Institute, January 1980.
[3] Postel, J., "Internet Name Server," USC/Information Sciences
Institute, IEN 116, August 1979.
[4] Sollins, K., "The TFTP Protocol," Massachusetts Institute of
Technology, IEN 133, January 1980.
[5] Postel, J., "Assigned Numbers," USC/Information Sciences
Institute, RFC 762, January 1980.
AI ELI5
On this page
§1Introduction
The User Datagram Protocol (UDP) provides a simple, connectionless transport service for applications that need to send datagrams without the overhead of connection setup, reliability guarantees, or flow control.
UDP is one of the two original transport protocols of the Internet protocol suite, alongside TCP. Where TCP provides reliability, UDP provides simplicity and speed.
UDP adds only a thin layer on top of IP: source and destination port numbers for multiplexing, a length field, and an optional checksum. The entire header is just 8 bytes.
UDP is a way for one program to send a short message to another program with almost no fuss. It does not set anything up first and does not promise the message arrives.
- UDP datagramThe sender fills in ports, length and checksum. There is no connection setup.
- UDP datagramIP hands it to UDP, which passes it to the program on the destination port. If it is lost or duplicated, UDP does not notice or retry.
§2Protocol Format
The UDP header is four 16-bit fields, eight octets in all, followed by the data octets. The RFC draws it as four 8-bit columns; the diagram below shows the same layout as a 32-bit-wide grid.
The message starts with a tiny label of four numbers: where it came from, where it is going, how long it is, and a check number. Then comes the message itself.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
SRC-PORT | Source Port | 2 bytes | optional (0 if unused) | Optional. When meaningful, the port of the sending process, and the port a reply should be addressed to absent other information. If not used, zero is inserted. |
DST-PORT | Destination Port | 2 bytes | Has a meaning within the context of a particular internet destination address. | |
LENGTH | Length | 2 bytes | >= 8 | Length in octets of this user datagram including the header and the data. The minimum value is 8. |
CHECKSUM | Checksum | 2 bytes | 16-bit one's complement of the one's complement sum of a pseudo header, the UDP header and the data, padded with zero octets if needed. All zeros transmitted means no checksum was generated. |
§3Fields
Each field in the UDP header serves a specific purpose:
Each of the four numbers has a job. The ports say which programs are talking, the length says how big the message is, and the checksum helps catch mistakes.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
PSEUDO-SRC | Source Address | 4 bytes | Source internet address, taken from the IP header. | |
PSEUDO-DST | Destination Address | 4 bytes | Destination internet address, taken from the IP header. | |
PSEUDO-ZERO | Zero | 1 byte | 0 | Zero octet. |
PSEUDO-PROTO | Protocol | 1 byte | 17 | IP protocol number for UDP. |
PSEUDO-LEN | UDP Length | 2 bytes | The UDP length. Protects against misrouted datagrams. |
§4Usage
UDP is the right transport choice when applications value speed and simplicity over guaranteed delivery:
Applications using UDP must handle their own reliability if needed (e.g., DNS retransmits queries, QUIC builds reliability on top of UDP).
If you want speed and can live with a lost message now and then, UDP is a good fit. If you need every piece to arrive in order, use TCP instead.
§5Applications
Many of the Internet's most important protocols rely on UDP as their transport:
The rise of QUIC (RFC 9000) has given UDP new prominence. QUIC builds a reliable, multiplexed transport on top of UDP, enabling HTTP/3 and demonstrating that UDP serves as an excellent foundation for innovation.
Name lookups, handing out addresses, telling the time and checking on devices all use short messages, so they use UDP.