UDP: minimal datagrams, application-owned semantics

UDP is a minimal message-oriented transport. It preserves datagram boundaries and provides ports, length, and a checksum, but it does not itself establish a connection, recover loss, order messages, regulate a receiver, or control congestion.

Mental model

• A successful UDP receive corresponds to a datagram. This differs from TCP's unstructured byte stream.
• No handshake means an application can send immediately, not that a response is guaranteed or that latency is always lower.
• Reliability, request correlation, replay protection, duplicate suppression, authorization, and congestion behavior belong to the application or a protocol above UDP.
• Large datagrams risk IP fragmentation. The safe payload depends on address family, path, encapsulation, and protocol profile.

Гарантии и границы

• UDP can detect some corruption through its checksum under the applicable IPv4 or IPv6 rules; it does not repair corruption.
• Delivery, uniqueness, ordering, and peer liveness are not UDP guarantees.
• A timeout is an ambiguous outcome: the request, response, or processing acknowledgement might have been lost.
• QUIC is not raw fire-and-forget UDP; it defines secure transport state and congestion-controlled recovery.

Сценарии диаграммы

One datagram preserves one message boundary. UDP adds ports, length, and checksum around an application datagram without a connection handshake.

Loss, retry, and duplicate suppression. UDP does not retransmit; if the application retries a mutation, it needs identifiers and duplicate handling.

Congestion control and path size. Choosing UDP does not exempt an Internet application from congestion control or safe datagram sizing.

QUIC builds a transport above UDP. QUIC uses UDP as a substrate but adds encryption, streams, reliability, loss recovery, and congestion control.

Архитектурные решения

• Use a mature UDP-based protocol where available. If designing one, define congestion control, pacing, timers, message sizing, authentication, amplification limits, and state exhaustion.
• Retry only with an operation identity and receiver-side semantics suitable for duplicates.
• Do not compare latency using invented fixed RTT counts; include DNS, transport reuse, TLS, processing, and network conditions in measurements.

Сбои и неоднозначные исходы

• Silent loss, ICMP filtering, NAT expiry, reordering, duplication, and fragmentation all need explicit handling.
• Unvalidated source addresses enable spoofing and amplification; bound response size until peer address validation where applicable.
• A busy receiver can drop datagrams without transport backpressure reaching the sender.

Операционный checklist

• Define maximum payload and path-MTU behavior.
• Congestion-control aggregate traffic, including retries and keepalives.
• Authenticate peers and bind request identifiers to intent.
• Measure loss, reorder, duplicate, timeout, NAT expiry, and receiver overload.

Связанная концепция

Первичные источники

1. https://www.rfc-editor.org/rfc/rfc768.html
2. https://www.rfc-editor.org/rfc/rfc8085.html
3. https://www.rfc-editor.org/rfc/rfc8899.html
4. https://www.rfc-editor.org/rfc/rfc4787.html
5. https://www.rfc-editor.org/rfc/rfc9000.html