Sending individual datagrams

UDP places an application message in a datagram with source and destination ports, length and checksum fields. Its basic header is eight bytes, and IP carries the result without a TCP-style connection setup.

The receiver handles separate datagrams rather than a continuous TCP byte stream. Sending one does not guarantee delivery, ordering or duplicate suppression.

The UDP checksum also covers an IP pseudo-header containing addressing and protocol information, helping detect misdelivery; this is not an extra transmitted UDP header. In IPv4, an all-zero checksum field means no checksum was generated, whereas a computed zero is encoded as all ones. IPv6 requires UDP checksums by default, with zero-checksum tunnel modes allowed only under separate conditions. “UDP checksums are optional” is therefore not a version-independent rule.

References: [1] [3] [4] [5]

Reliability must come from elsewhere

Some applications can discard stale information; others add acknowledgments, recovery and session state above UDP. Choosing UDP alone therefore does not determine whether the whole application is reliable or real-time.

The checksum detects transmission errors rather than authenticating a sender. Ports likewise identify transport endpoints, not trusted identities; applications needing cryptographic protection require additional mechanisms.

References: [1] [2]

Message size and congestion costs

UDP has no built-in congestion controller, but Internet applications must still prevent congestion collapse and share capacity with other traffic. Absence of a handshake does not remove resource constraints.

Large datagrams can trigger IP fragmentation, where losing one fragment prevents reassembly of the entire packet. RFC 8085 consequently treats path MTU and fragmentation as application-design concerns.

References: [2]