Introduction to UDP
TCP provides an ordered, reliable byte stream, whereas the User Datagram Protocol (UDP) sends messages as independent datagrams. A sender passes a datagram to IP with a destination address and port. The receiver handles each datagram as a separate unit, and UDP does not combine successive datagrams into a byte stream. UDP itself does not acknowledge receipt or retransmit lost datagrams. It also does not define their order, so two datagrams sent in sequence may arrive in a different order, fail to arrive, or be duplicated.
UDP is part of the Internet protocol suite and operates at the transport layer, like TCP. Its service scope is smaller because the protocol does not establish a connection and does not provide a reliable, ordered byte stream. It gives applications a simple mechanism for sending messages called , from one application to another.
UDP limits its transport functions to datagram delivery, checksum processing, and port-based multiplexing. It does not provide the reliability, ordering, or flow control supplied by TCP, so it does not require TCP-style retransmission and acknowledgment mechanisms. Its small header and lack of connection establishment can reduce protocol overhead and processing delay. UDP itself does not guarantee speed or low latency. Delay-sensitive applications, including some video and online gaming services, may prefer the absence of automatic retransmission and handle loss at the application layer. This model is useful when keeping data current matters more than delivering every part of a message.
Characteristics of UDP
UDP provides datagram delivery without guarantees, checksum processing, and multiplexing through port numbers. If reliability, ordering, or congestion control is required, the application or a protocol running over UDP must provide it.
- Connectionless
UDP is a connectionless transport protocol. UDP itself does not establish a connection before sending data and does not perform the three-way handshake used by TCP. An application using UDP can create a datagram, specify a destination address and port, and pass it to the network. The first datagram can carry application data because UDP does not require a transport connection handshake.
Removing connection establishment avoids the exchange of messages required before TCP data can be sent. This can reduce initial latency and endpoint state, but it does not guarantee a particular delivery time.
- Unreliable best-effort delivery
UDP provides best-effort delivery, with no guarantee of success. Neither UDP nor the underlying IP network guarantees delivery, freedom from duplication, or ordering. UDP itself does not provide the following mechanisms:
- Acknowledgments: UDP does not send the sender an acknowledgment that a datagram was received. An application can define its own acknowledgment messages.
- Retransmission: If a datagram is lost in transit, UDP does not retransmit it automatically. The application may take responsibility for sending it again.
- Data ordering: UDP datagrams are independent entities. If a sender sends datagram A followed by datagram B, the network may deliver B before A, deliver both, deliver neither, or deliver a duplicate. UDP does not reorder them at the destination.
- Low overhead and simple processing
A UDP header has a fixed size of 8 bytes, while a basic TCP header is at least 20 bytes and contains more fields for reliable byte-stream delivery. For the same payload, UDP therefore sends less transport control data, although overall efficiency still depends on the application and network.
UDP does not require the protocol to maintain connection state, retransmission counters, acknowledgment tracking, or window mechanisms. An implementation still may maintain socket buffers and state, but the smaller service scope can reduce processing cost and datagram-handling latency.
- No built-in flow or congestion control
UDP has no built-in flow-control or congestion-control mechanisms. An application can send datagrams without a protocol mechanism that automatically matches its rate to the receiver or to the path capacity. A constant rate may be useful for some applications, but uncontrolled transmission can increase congestion and loss for other flows. UDP applications should therefore implement suitable rate and congestion control.
The UDP header and its fields
The UDP header contains four fields, each 16 bits (2 bytes) long. Their combined fixed size is 8 bytes, followed by the application data.
Detailed field descriptions
1. Source port (16 bits)
This field identifies the port of the sending process. In TCP, the port contributes to identifying a stateful connection, whereas in UDP it is optional and may be set to zero when the sender does not need to receive a reply on that port. In ordinary exchanges it is set because the receiver can use it as the destination port for a reply. When a DNS client sends a query, the server usually directs the response to the source port of the incoming datagram. A zero source port does not identify a port to which a reply can be sent by default.
2. Destination port (16 bits)
This field is present in every UDP header, identifies the destination application port, and together with the IP addresses helps select the receiving endpoint. It is central to UDP's ability to perform . The receiver's operating system uses this field with its address and socket context to deliver the datagram to the correct process among many that may be running.
3. Length (16 bits)
This field specifies the total length of the UDP datagram in bytes. This length includes the 8-byte UDP header itself plus the length of the application data (the payload). The minimum possible value is 8, representing a UDP datagram with an empty payload. For an ordinary datagram, the field is limited to 65,535 bytes. For an IPv6 jumbogram, RFC 2675 permits a zero Length field and derives the actual length from the Jumbo Payload option. The checksum calculation uses that actual length.
4. Checksum (16 bits)
This field provides a basic mechanism for error detection in the UDP header and data. The checksum is the 16-bit one's complement of the one's complement sum of the UDP header, payload, and a special pseudo-header. If the number of octets is odd, a zero octet is added at the end for the calculation. If the computed result is zero, the transmitted value is 0xFFFF, because a zero field value means that no checksum was generated.
The pseudo-header is not transmitted as part of the datagram. It includes the source and destination IP addresses, protocol number 17, and the UDP length. Including these fields helps prevent a datagram sent to another host or altered in transit from being accepted.
The usage policy depends on the IP version.
- In IPv4, the UDP checksum is optional. If the sender does not calculate it, the field is set to zero. A no-checksum mode can reduce processing cost, but it removes this protection against data corruption. A receiver may be configured to discard datagrams without a checksum, and a host implementation must generate checksums by default.
- In IPv6, the UDP checksum is mandatory in the ordinary mode. IPv6 has no header checksum of its own, so the UDP checksum also covers the IPv6 pseudo-header. The sender must calculate it and a receiver discards a datagram whose value is zero. An exception can apply to specified UDP tunnels that meet the requirements for IPv6 zero-checksum mode.
UDP applications and use cases
UDP is useful for applications where keeping data current matters more than delivering every message, or where the application manages reliability itself.
Real-time and streaming applications
For services such as Voice over IP (VoIP), video conferencing, and live video streaming, data that arrives with high delay may be less useful than data that was lost. A TCP retransmission of a lost voice packet could arrive too late to be played in the conversation and could cause a pause. The application may skip the lost packet and play the next one, accepting a small audio glitch. UDP does not guarantee low latency, but the absence of protocol-level retransmission can make real-time handling easier.
Online gaming
In fast-paced online games, the latest information about a player's position or action is often the most useful. An old, retransmitted packet containing a player's position from half a second ago may be stale and increase display delay. Many games use UDP and build their own update, numbering, and synchronization logic on top of it.
Simple query-response protocols
Protocols with a small request and a small response can use UDP. A classic example is the Domain Name System (DNS). In a typical query, a client sends a UDP datagram containing a domain name, and the server replies with a datagram containing response data such as an IP address. If a datagram is lost, the resolver can wait for a timeout and send the query again. Establishing and closing a TCP connection would add overhead to this exchange, although DNS can also use TCP in situations specified by its protocol. DHCP is another example.
Multicast and broadcast services
UDP is often used for multicast and broadcast services, where one datagram can reach many destinations. TCP does not directly provide one-to-many IP multicast or broadcast delivery. UDP's connectionless model lets a sender transmit one stream of datagrams, while multicast mechanisms can replicate it at network branches leading to receivers. Broadcast is usually limited to a local subnet.
Reliability Mechanisms over UDP
UDP does not provide acknowledgments, retransmissions, or datagram ordering. If an application requires these functions, it must implement them in a protocol running over UDP or choose a transport that provides them.
An application protocol can apply sequence numbers, acknowledgments, and retransmissions only to selected data. In a network game, text messages may be retransmitted, while obsolete player-position updates may be replaced by newer data.
QUIC is an example of a transport protocol that runs over UDP. RFC 9000 specifies that QUIC is a name, not an acronym. QUIC establishes a stateful connection, and its packets are carried in UDP datagrams. It provides ordered, reliable streams, loss recovery, and congestion control, and integrates the security handshake with TLS 1.3. RFC 9221 also defines DATAGRAM frames for application data without retransmission while retaining QUIC congestion control. HTTP/3 uses QUIC as its transport protocol.