Cloud Parts

UDP

The User Datagram Protocol: ports and a checksum on top of IP, and nothing else. Each datagram is sent on its own, with no connection, no retransmission and no ordering.

What it is
Network protocols (transport protocols)
Type
Open source
Made by
IETF
License
Open standard (IETF RFC)
Facts checked
8 October 2026
Website

What it is

UDP adds just enough to IP for one program to send a message to another: an 8-byte header with a source port, a destination port, a 16-bit length and a checksum computed over the data and the addresses. There is no handshake, no connection state and no acknowledgement. Each sendto becomes one datagram that may arrive once, twice or not at all, and datagrams can overtake each other. The receiver gets whole datagrams, so unlike TCP the message boundaries survive, but anything an application needs beyond that it has to build itself: retries, duplicate detection, ordering and, by IETF guidance, congestion control.

That minimalism is the point. A DNS query fits in one datagram to port 53 and one back, with no setup round trip. Voice, video and game traffic would rather skip a lost packet than wait for a resend that arrives too late. And because UDP adds so little, new transports are built on top of it: QUIC, which carries HTTP/3, runs its own reliability, congestion control and TLS encryption inside UDP datagrams, so it can be deployed in applications without changing operating system kernels or middleboxes. The IETF’s UDP usage guidelines (RFC 8085, BCP 145) are the reference for doing this safely.

Why teams pick it

  • No handshake: a request and its answer can take one round trip in total, as in a DNS lookup
  • Message boundaries are kept, and there’s almost no per-flow state on either host
  • A blank slate for new transports: QUIC builds reliability, streams and encryption on UDP and ships them in applications rather than kernels
  • A lost packet doesn’t hold up the ones behind it, which suits live audio, video and game state

Watch out for

  • No delivery, ordering or duplicate protection: an application that needs them must implement them
  • No congestion control: a sender can flood a path, so applications must limit their own rate (RFC 8085)
  • Datagrams larger than the path MTU get fragmented, and some NATs and firewalls drop fragments; RFC 8085 says not to exceed the MTU
  • Middleboxes forget idle UDP flows: NATs must keep state for at least 2 minutes, but many use shorter timeouts, so long-lived sessions need keep-alives (no more often than every 15 seconds)
  • Some networks block UDP outright: 3% to 5% in measurements cited by the IETF

Alternatives

What all transport protocols have in common →
QUICOpen sourceA secure, multiplexed transport over UDP: TLS 1.3 is built into its handshake, many streams share one connection without blocking each other, and a connection can survive a change of network.TCPOpen sourceThe Transmission Control Protocol: a handshake opens a connection between two ports, then bytes arrive complete and in order, resent when lost and paced to what the path can carry.

How it fits with other technologies

Send and receive one datagram, no connection needed · python

import socket

rx = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
rx.bind(("127.0.0.1", 0))  # the OS picks a free port

tx = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
tx.sendto(b"cpu=0.42", rx.getsockname())  # no handshake: one datagram goes out

data, sender = rx.recvfrom(1500)
print(data, sender)  # e.g. b'cpu=0.42' ('127.0.0.1', 50823)

See it in a real stack

No architecture uses UDP yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from1980–2022

Not every use of the new Internet protocols wanted a connection. Jon Postel’s RFC 768, dated 28 August 1980 and three pages long, defined UDP to give programs “a minimum of protocol mechanism”: a transaction-oriented datagram service on top of IP, with “delivery and duplicate protection” explicitly not guaranteed. It named its two main users: the Internet Name Server and the Trivial File Transfer Protocol. Anything needing ordered, reliable delivery was told to use TCP.

The specification has never been replaced. DNS (RFC 1035, 1987) sent standard queries over UDP port 53 and left retransmission to the resolver. In 2017 the IETF published RFC 8085, guidelines on congestion control, message size, reliability and middleboxes for anyone building on UDP. Its biggest new user came in May 2021: QUIC (RFC 9000), the transport under HTTP/3, carries its packets in UDP datagrams so that it can pass through existing networks and be implemented outside the kernel.

Why it’s built this way

Leave reliability to the application
A name lookup is one question and one answer. Retrying it is cheaper than setting up and tearing down a connection, so UDP sends the datagram once and lets the program decide whether and when to ask again.
Keep the same checksum as TCP, but make it optional
RFC 768 computes the checksum over a pseudo header with the IP addresses, to catch misrouted datagrams, and lets a sender put zero to skip it. On IPv6, which has no header checksum of its own, RFC 8085 says the UDP checksum must be used.
Ports and nothing more
With only an 8-byte header, UDP stays a thin layer that other protocols can build on. That’s what let QUIC add streams, loss recovery and encryption decades later without any change to the network.

Timeline

  1. 1980

    RFC 768 defines UDP, for name servers and TFTP

  2. 1987

    DNS (RFC 1035) recommends UDP port 53 for standard queries

  3. 2017

    RFC 8085 publishes UDP usage guidelines as BCP 145

  4. 2021

    QUIC (RFC 9000) runs a full transport inside UDP datagrams

  5. 2022

    HTTP/3 (RFC 9114) brings web traffic to UDP port 443

Sources5 · facts checked 8 October 2026

Improve this page on GitHub