UDP: Connectionless Transport

UDP, specified in RFC 768, is a connectionless transport-layer protocol: sending a UDP datagram requires no prior handshake, no shared state, and no negotiated parameters between sender and receiver. Each datagram is handled independently by the network and by the receiving socket, with no notion of a "connection" persisting between messages. This is in sharp contrast to TCP, which establishes a connection (a three-way handshake), maintains per-connection state (sequence numbers, window sizes, timers), and treats data as a continuous byte stream. UDP is also message-oriented rather than byte-stream-oriented. Each `send()` call from the application produces exactly one UDP datagram, and each successful `recv()` call at the receiver yields exactly one whole datagram — never a partial one, never multiple concatenated ones. This preserves application-level message boundaries, which matters for protocols like DNS where each query and response is a self-contained unit. TCP offers no such guarantee: it may split or coalesce writes arbitrarily. Because UDP has no per-connection state, it is unreliable: datagrams may be lost, duplicated, corrupted, or delivered out of order by the underlying network, and UDP does nothing to detect or correct any of this except for bit-error detection via an optional checksum. It provides no flow control (a fast sender can overwhelm a slow receiver's buffer, causing silent drops) and no congestion control (a UDP sender does not slow down when the network is congested — a property that makes UDP potentially unfair to competing TCP flows, and that motivates congestion control being implemented at the application layer, e.g., inside QUIC). What UDP does guarantee is minimal overhead: an 8-byte header versus TCP's minimum 20 bytes, and no round trip spent on connection setup before the first byte of data can be sent.

Segment structure

A UDP segment (informally, "datagram") consists of an 8-byte header followed by the application payload: ``` 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | Source Port | Destination Port | +-------------------------------+-------------------------------+ | Length | Checksum | +-------------------------------+-------------------------------+ | | | Application Data | | | +----------------------------------------------------------------+ ``` Each field is exactly 16 bits (2 bytes):

• Source Port (16 bits): the sending process's port, used so the receiver can reply. May be all-zero if no reply is expected.
• Destination Port (16 bits): identifies the receiving process/socket on the destination host — this is the field that drives demultiplexing.
• Length (16 bits): the total length in bytes of the UDP header plus data (minimum value 8, for a header with zero-length payload).
• Checksum (16 bits): a 1's-complement checksum over a pseudo-header, the UDP header, and the data, used to detect transmission errors. May be all-zero to indicate "no checksum computed" over IPv4 (mandatory over IPv6).

Demultiplexing

The receiving host's transport layer uses the (destination IP, destination port) pair — with UDP itself needing only the destination port, since UDP is connectionless — to decide which socket's receive buffer gets the datagram. This is connectionless demultiplexing: a socket bound to port `P` receives every incoming datagram addressed to port `P`, regardless of the sender's IP address or port. This differs from TCP's connection-oriented demultiplexing, which uses the full four-tuple (source IP, source port, destination IP, destination port) to route segments to a specific connected socket. ``` DEMULTIPLEX(datagram): dst_port = datagram.header.destination_port socket = lookup_socket_bound_to(dst_port) if socket is None: send_ICMP_port_unreachable(datagram.source) return if socket.receive_buffer.is_full(): drop(datagram) # silent loss — no NACK, no retransmit request return socket.receive_buffer.enqueue(datagram) ```

The checksum algorithm

The checksum is UDP's only defense against corrupted data, and it is optional over IPv4 but effectively always used in practice. It is computed over three things concatenated: a 12-byte pseudo-header (drawn from the IP header: source IP, destination IP, protocol number, UDP length), the UDP header itself (with the checksum field set to zero during computation), and the payload, padded to an even number of bytes with a zero byte if necessary. ``` COMPUTE_CHECKSUM(pseudo_header, udp_header_with_zero_checksum, data): words = split_into_16_bit_words(pseudo_header + udp_header_with_zero_checksum + pad_to_even(data)) sum = 0 for w in words: sum = sum + w while sum > 0xFFFF: # fold any carry back in (end-around carry) carry = sum >> 16 sum = (sum & 0xFFFF) + carry checksum = ones_complement(sum) # bitwise NOT, 16 bits if checksum == 0x0000: checksum = 0xFFFF # avoid confusion with "no checksum" sentinel return checksum VERIFY_CHECKSUM(received_segment): words = split_into_16_bit_words(pseudo_header + full_udp_segment) # checksum field included as-is sum = 0 for w in words: sum = sum + w while sum > 0xFFFF: carry = sum >> 16 sum = (sum & 0xFFFF) + carry result = ones_complement(sum) return result == 0x0000 # all 1s complement of all-1s sum means no detected corruption ``` The key algebraic fact making verification work is that 1's-complement addition of a value and its own complement yields all 1-bits (`0xFFFF` for 16-bit words). If the sender's checksum field is filled with `C = ~(S)` where `S` is the sum of all other words, then the receiver's sum over all words (including `C`) becomes `S + ~S`, which in 1's complement arithmetic equals `0xFFFF`, and its complement is `0x0000`. Any single-bit or odd-parity corruption during transit almost always breaks this identity, so the receiver detects it. It is not perfect: certain patterns of compensating errors (e.g., an error that adds `k` to one word and subtracts `k` from another) can go undetected, which is why checksum is a probabilistic error-detection tool, not a cryptographic guarantee.

Sending path

``` UDP_SEND(app_data, src_port, dst_ip, dst_port): header = build_header(src_port, dst_port, length = 8 + len(app_data)) header.checksum = 0 pseudo = build_pseudo_header(local_ip, dst_ip, PROTO_UDP, header.length) header.checksum = COMPUTE_CHECKSUM(pseudo, header, app_data) segment = header + app_data pass_to_IP_layer(segment, dst_ip) # fire-and-forget: no ack expected, no retry scheduled ``` There is no connection-establishment step, no sequence number, and no retransmission timer armed after this call returns — the application layer, if it needs those guarantees, must implement them itself on top of UDP.

Time complexity of sending/receiving one datagram. Building the header and computing the checksum both take `O(n)` time, where `n` is the datagram length in 16-bit words (i.e., `O(payload size)`), because the checksum algorithm makes a single linear pass, summing each word once with `O(1)` amortized work per word (carries fold in constant time per word since a 32-bit accumulator can absorb at most one carry per addition of two 16-bit values). Demultiplexing is `O(1)` expected time with a hash-table lookup keyed by port number. There is no connection-setup cost (`O(1)` — literally zero handshake messages), in contrast to TCP's `O(1)` messages but nonzero latency (one RTT) for the three-way handshake before data flows.

Space complexity. UDP requires only `O(1)` additional state beyond the socket's receive buffer: a source port, a destination port, and (implementation-dependent) a small queue of unprocessed datagrams per socket. This is far less than TCP, which must retain `O(window size)` bytes of unacknowledged data for potential retransmission, plus per-connection timers, sequence counters, and congestion-control state.

Correctness of the checksum. The claim to verify is: if no error occurs, the receiver's verification always succeeds, and if certain classes of errors occur, verification always fails. The proof rests on properties of 1's complement arithmetic treated as arithmetic modulo `2^16 - 1` (with the caveat that `0` and `2^16-1` are both representable as "all zero bits" and "all one bits" respectively, requiring the "map 0 to all-ones" rule in the checksum-computation step). No-error case. Let `S` be the 1's-complement sum of all words excluding the checksum field, and let `C = onesComplement(S)`. At the receiver, summing all words including `C` gives (in 1's-complement arithmetic) `S + C = S + (M - S) = M`, where `M` represents the all-ones value acting as the additive identity's complement in this number system; concretely, adding a value and its bitwise complement in 1's-complement arithmetic always produces all 1-bits. Complementing all 1-bits yields all 0-bits, so `VERIFY_CHECKSUM` returns true. This shows the protocol has no false positives when the segment is untouched. Error-detection guarantee (partial). If exactly one bit flips anywhere in the covered region, the sum `S'` at the receiver differs from `S`, so `S' + C ≠ 0xFFFF...`, and verification correctly fails — a single bit-flip is always detected. More generally, any odd number of bit-errors within a single 16-bit word is always detected, because such an error changes the parity of that word's contribution to the sum, and the folding/complement arithmetic cannot silently cancel a parity change within one word. The known blind spot is when errors in different words cancel under modular addition (e.g., one word increases by `x` while another decreases by exactly `x`), which is why the checksum is a heuristic, not a cryptographic integrity guarantee — an adversary or extremely unlucky corruption pattern can defeat it. This is the fundamental honest tradeoff: checksums are cheap (`O(n)`, no cryptographic key material) but only probabilistically reliable, unlike a cryptographic MAC.

Correctness of "no guarantees" as a design, not a bug. UDP's specification makes no claim about delivery, order, or duplication, so there is nothing to "prove wrong" — the protocol correctly implements exactly what it promises: best-effort, unordered, unreliable message delivery with optional corruption detection. Any stronger property (ordering, retransmission, congestion response) is, by construction, the application's responsibility, which is the seed of the reliability mechanisms built in Principles of Reliable Data Transfer.

Consider a DNS client on port `51234` sending a query to a DNS server on port `53`, with a 4-byte payload `0x0001 0x0001` (a trivially small "message" for illustration — imagine it represents a compressed query ID and flags). We trace the checksum computation by hand.

Setup.

Step 1 — list all 16-bit words to sum (pseudo-header, then UDP header with zeroed checksum, then data): ``` 0x0A00 0x0001 0x0A00 0x0002 0x0011 0x000C 0xC822 0x0035 0x000C 0x0000 0x0001 0x0001 ```

Step 2 — sum with end-around carry, accumulating in a wider register and folding overflow back: ``` running = 0x0A00 running += 0x0001 -> 0x0A01 running += 0x0A00 -> 0x1401 running += 0x0002 -> 0x1403 running += 0x0011 -> 0x1414 running += 0x000C -> 0x1420 running += 0xC822 -> 0xD842 running += 0x0035 -> 0xD877 running += 0x000C -> 0xD883 running += 0x0000 -> 0xD883 running += 0x0001 -> 0xD884 running += 0x0001 -> 0xD885 ``` No 16-bit overflow occurred in this particular trace (every partial sum stayed under `0x10000`), so no carry-folding step is triggered here; final sum `S = 0xD885`.

Step 3 — 1's complement. ``` C = ~S = ~0xD885 = 0x277A ``` `C = 0x277A` is not all-zero, so no sentinel substitution is needed. This is the value placed in the Checksum field of the transmitted segment.

Step 4 — receiver verification. The receiver reconstructs the same pseudo-header, then sums all words of the received segment, this time including the actual checksum field `0x277A` instead of `0x0000`: ``` running = 0xD885 (sum of everything except checksum, as before) running += 0x277A -> 0xFFFF ``` `0xFFFF` complemented is `0x0000`, so `VERIFY_CHECKSUM` returns true: no corruption detected, matching the fact that we did not actually corrupt anything in transit. If a single bit had flipped in, say, the data word `0x0001 → 0x0003` during transmission, the receiver's running sum would become `0xD887 + 0x277A = 0x10001`, which folds (carry of `1` added back) to `0x0002`, whose complement `0xFFFD ≠ 0x0000` — verification correctly fails, and the datagram is silently dropped (UDP does not request retransmission; it merely discards it or flags it as errored to the application, depending on OS configuration).

UDP's design descends directly from the same philosophy that shaped the early internet's layered architecture: push complexity to the edges, keep the core simple (the end-to-end argument). It was formalized by David P. Reed, who argued that a bare, unreliable datagram service — distinct from the reliable, connection-oriented service that would become TCP — needed to exist as a first-class transport option, since some applications are better served by minimal transport with reliability logic implemented precisely where it is needed.

DNS relies on UDP for the vast majority of queries because a single small request-response pair does not justify a TCP handshake's round trip, and the resolver itself implements a simple retry-on-timeout mechanism if a reply never arrives. VoIP and video conferencing tools (RTP over UDP) prefer dropping a stale audio/video frame over waiting for its retransmission, since a late frame is often worse than no frame. Online multiplayer games send frequent, small, loss-tolerant position updates over UDP, layering their own lightweight reliability only on critical events (e.g., "player fired weapon") while letting routine state updates drop freely. DHCP, SNMP, and NTP all use UDP for low-overhead, often broadcast/multicast-friendly communication. Perhaps most significantly, modern web transport is migrating toward QUIC (the transport underlying HTTP/3), which is built entirely on top of UDP specifically to escape kernel-level ossification of TCP and to implement its own multiplexed streams, congestion control, and encryption — a direct, large-scale validation of UDP's original design bet that giving applications a bare, minimal transport primitive would let them build exactly the reliability semantics they actually need. Understanding UDP is therefore a prerequisite for understanding both classic lightweight services and cutting-edge transport redesigns, and it complements the multiplexing concepts introduced in Transport-Layer Services and Multiplexing.

Ask the tutor: How would you design a minimal application-layer acknowledgment scheme on top of UDP to recover just enough reliability for a file-transfer tool, without reimplementing all of TCP?