UDP: Send and Forget

UDP sends each message as one datagram and makes no promise about it: there is no connection to set up, no acknowledgement, no retransmission and no ordering. What it adds to IP is a port number at each end, so the datagram reaches the right program, and a checksum, so a corrupted datagram is discarded rather than delivered.

The whole header is eight bytes, four fields of two bytes each.

What UDP leaves out is the point of it.

No handshake. The first datagram carries data. A DNS lookup is one datagram out and one back, so the answer arrives in a single round trip.

No retransmission. A lost datagram stays lost. If the application wants it again, the application must notice and ask.

No ordering. Datagrams can arrive in a different order from the one they were sent in, and UDP hands them over as they come.

Message boundaries are kept. A program that sends a 300-byte datagram and then a 500-byte one, and receives both, receives them as two messages of 300 and 500 bytes. TCP, by contrast, delivers one unbroken stream of bytes.

Those absences suit two kinds of program. The first sends small, independent questions where a retry is cheap: DNS, and the network time protocol. The second sends a constant flow where old data is worthless once new data exists: voice and video calls, live streams, and online games, where a late sound sample or a stale position is better skipped than waited for.

Because UDP is so thin, it is also the base for protocols that build their own rules. QUIC, the transport under HTTP/3, runs on UDP and adds its own reliability and encryption, which lets it be changed without waiting for every operating system to update.

So reach for UDP when each message stands alone, or when waiting for a lost one costs more than going without it.