RFC 768 · · Internet Standard
UDP, the protocol that promises nothing.
The official title is "User Datagram Protocol." What it actually decides: how to send a message across the internet with no handshake, no ordering, and no promise it arrives. Three pages, written in 1980, and still carrying DNS, video calls and HTTP/3.
Written by Noel Lang · IT trainer
TL;DR
RFC 768 defines UDP, and it is three pages long. A UDP packet is an eight-byte header, four 16-bit fields (source port, destination port, length, checksum), followed by your data. There is no connection, no retransmission, no ordering and no congestion control. That sounds like a weakness, and it is exactly why DNS, DHCP, live video and HTTP/3 all choose it: they would rather handle loss themselves than wait.
The problem it solves
By 1980 the internet already had RFC 793 , which delivers a stream of bytes reliably, in order, no matter what the network does to it. TCP is superb, and it is expensive: before a single byte of your data moves, both ends exchange greetings, and afterwards they keep state about everything that might need resending.
For a lot of traffic that price buys nothing. A DNS query is one small question with one small answer. Setting up a connection to ask it costs more round trips than simply asking twice would. So RFC 768 offers the other deal: a header thin enough to be almost nothing, and no promises whatsoever. Send it, and hope.
The result is the smallest useful thing you can put on top of IP. It adds exactly two ideas to a raw IP packet: port numbers, so one machine can run more than one service, and a checksum, so corruption is noticed. Everything else it deliberately leaves to you.
The postcard
RFC 793 is a registered letter. The post office confirms you sent it, tracks it, retries if it goes astray, and tells you when it arrived. All of that costs time, paperwork and a filing cabinet at each end.
UDP is a postcard. You write the address, drop it in the box, and walk away. Nobody confirms it arrived, nobody notices if it did not, and if you send three they may show up in any order. The postcard is not a defective letter. It is the right object when the message is small, the loss is survivable, and waiting for confirmation would cost more than the message is worth.
The analogy holds at the awkward edges too. Postcards can be read by anyone, and UDP has no encryption of its own. Postcards get delivered to the wrong door, and UDP’s pseudo-header checksum exists to catch exactly that. And when you truly need certainty about a postcard, you build your own tracking system on top, which is precisely what QUIC did.
The entire protocol, in eight bytes
Four 16-bit fields, then your data. Compare this to the twenty-byte minimum header of RFC 793 , with its sequence numbers, acknowledgements and window sizes, and the philosophy is visible at a glance.
What the RFC actually says
Three pages, and one of them is mostly the diagram above. If you ever want to read an internet standard end to end, start here:
| Section | In plain words |
|---|---|
| Format | One diagram: four 16-bit fields, eight bytes, then your data. That diagram is most of the protocol. |
| Fields | What each field means. The source port is optional and may be zero. The length counts the header too, so the minimum legal value is 8. |
| User Interface | Two sentences on what an application must be able to ask for. An unusually humble section. |
| IP Interface | The pseudo-header trick: the checksum secretly also covers the IP source and destination addresses, so a misdelivered packet is caught. |
| Protocol Application | Names two users of UDP as examples, one of them the "Internet Name Server". In 1980, DNS did not have its name yet. |
| Protocol Number | Seventeen. That is the whole section. |
Things people get wrong
-
"UDP is unreliable, so it is the worse protocol."
It is unreliable by design, which is not the same as broken. UDP does not lose your data on purpose; it simply declines to fix loss for you, and hands that decision to the application. That is why QUIC, and therefore HTTP/3 and a large share of the modern web, is built on UDP: the designers wanted reliability, but on their own terms rather than TCP's.
-
"UDP has no error checking."
It has a 16-bit checksum, and a clever one: it covers the header, the data, and a pseudo-header carrying the IP source and destination addresses, so a packet delivered to the wrong host gets caught. In IPv4 a sender may send all zeros to mean "not computed". In IPv6 the checksum is mandatory, because IPv6 removed the header checksum that used to catch those errors one layer below.
-
"UDP is faster than TCP."
It has lower latency, which is a different thing. No handshake means the first packet carries real data instead of a greeting, and no retransmission means nothing waits for a straggler. But on a clean link, a large file transfer over TCP will usually beat one hand-rolled over UDP, because TCP has spent forty years learning how fast it is allowed to go.
Where you'll meet UDP
Every name you look up and every video call you make. A field guide:
| You see | What's happening |
|---|---|
| A DNS lookup on port 53 | Almost always UDP. Query out, answer back, one packet each. Falls back to TCP only when the answer does not fit. |
| HTTP/3 and QUIC on port 443 | The modern web runs over UDP. QUIC rebuilt reliability on top of it, precisely because it wanted control that TCP would not give. |
| DHCP on ports 67 and 68 | A device with no address yet cannot do a TCP handshake. UDP broadcast is the only thing that works before you have an identity. |
| Syslog on port 514 | Log lines shipped fire-and-forget. Losing one line in a flood beats blocking the application that wrote it. |
| A video call that goes blocky | Packets were lost and nobody asked for them again. A late frame is worthless, so UDP lets it go. |
traceroute on Linux |
The classic implementation sends UDP packets to improbable high ports and listens for the ICMP errors coming back. |
Questions people actually ask
What is RFC 768? +
RFC 768 is the 1980 specification of UDP, the User Datagram Protocol. It defines a minimal way to send a message over IP: an eight-byte header with source port, destination port, length and checksum, and nothing else. There is no connection setup, no retransmission and no ordering. It is three pages long and still an Internet Standard (STD 6).
What is the difference between UDP and TCP? +
TCP establishes a connection, retransmits lost data, puts packets back in order and slows down when the network is congested. UDP does none of that: it hands your message to IP and forgets about it. TCP is a registered letter, UDP is a postcard. Choose UDP when losing a packet matters less than waiting for it, which is why live video and DNS use it.
Does UDP have a checksum? +
Yes. UDP carries a 16-bit checksum that covers the header, the data, and a pseudo-header containing the IP source and destination addresses. In IPv4 it is optional: a sender may transmit all zeros to mean "not computed". In IPv6 the checksum is mandatory, because IPv6 dropped the header checksum that used to catch those errors one layer down.
Why do DNS and video calls use UDP? +
Because retrying is cheaper than waiting. A DNS query and its answer fit in one packet each; if one is lost, asking again costs less than a TCP handshake would have. In a video call, a frame that arrives late is worthless anyway, so there is nothing to gain from retransmitting it. UDP lets the application decide what to do about loss instead of forcing one answer on everyone.
Referenced by
Other explainers on this site that point back to this RFC:
How RFC 768 connects
Its counterparts
-
RFC 793 · the careful sibling
TCP, the other choice
The same year, the same layer, the opposite philosophy. TCP guarantees delivery and order at the price of latency and state. Nearly every design decision in one is the mirror of the other.
-
RFC 9868 · updates this one
Options for a protocol with no options
From 2025: a way to add optional fields to UDP after all, tucked into the space between the length field and the end of the IP packet. Forty-five years later, the protocol that promised nothing grew a pocket.
Part of a guided cluster: The networking basics, explained