RFC 768 / START HERE
UDP, before the details
UDP: User Datagram Protocol
UDP lets an application send individual messages, called datagrams, to another application. It adds ports to identify the receiving application, with very little transport machinery.
The idea in one picture
An app sends one datagram
The network carries it
The receiving app handles the message
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
Some applications prefer to handle timing, retries, or reliability themselves. UDP does not guarantee delivery or ordering.
A familiar example
A DNS lookup can be sent as a small UDP message. If no reply arrives, the requesting software decides what to do next.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Preserve a datagram boundaryUDP sends discrete application messages with very little transport mechanism.→
- Demultiplex using portsA destination port selects a receiving application in the context of the destination IP address.→
- Count the header and dataThe UDP header is eight octets; the Length field includes both that header and the payload.→
- Check a datagram’s integrityThe UDP checksum includes a pseudo-header from IP, the UDP header, and the data.→
- Separate UDP from application reliabilityUDP’s interface supplies addresses, ports, and datagrams; delivery policy belongs above this minimal service.→
This introduction explains RFC 768 (1980). Read the original RFC ↗