skip to content

UDP is called connectionless: what state do two UDP endpoints share, and what does that leave the application to work out itself?

level: middleimportance: should knowfreq 42%

answer

  1. no handshake, no teardown
  2. every datagram fully addressed
  3. silence is the only goodbye
  4. no TIME-WAIT for UDP
  5. ICMP Port Unreachable, asynchronously

basics

~20 s

None: UDP has no handshake, sequence numbers or teardown, so each datagram stands alone with full addressing. The application must detect a vanished peer, check each datagram's sender, and tolerate late datagrams meant for an earlier user of the port.

solid answer

~40 s

UDP keeps no shared state at all. There is no handshake before the first datagram, no sequence or acknowledgement numbers, and no close exchange; every datagram carries its full addressing — ports in the UDP header, addresses in the IP header — and is processed on its own. The consequences land in the application. The first datagram carries data immediately, with no setup round trip. A receiver cannot tell a peer that stopped sending from one that crashed; silence is the only signal, so sessions need timeouts. One socket can receive from any source, so RFC 8085 §5 says applications MUST check the source themselves or have the stack filter it. And because UDP has no `TIME-WAIT`, a new application on a reused port can receive delayed datagrams meant for the previous one.

go deeper

for a junior

Recall that UDP has no handshake and no close: each datagram is sent and received on its own, with its full addressing.

for a middle

Explain what shifts to the application: peer timeouts, source checks, ICMP errors arriving asynchronously, and stale datagrams on a reused port.

for a senior

Show how you would build session state on top — identifiers, idle timeouts, keepalives through middleboxes — and why an unverified source address changes what you trust.

for a principal

Judge when statelessness is the asset, as for a server answering huge numbers of one-shot queries, and when rebuilding sessions costs more than a connection-oriented transport.

## What "connection state" would mean A **connection** is state that two endpoints agree on and keep in step. In TCP it lives in each side's transmission control block: the pair of sockets that names the connection, initial sequence numbers exchanged in the handshake, send and receive windows, and a position in the state machine from `LISTEN` to `TIME-WAIT`. RFC 9293 defines a connection by exactly that **pair of sockets**, and both ends must create and tear it down together. UDP has none of this. RFC 768's header has four fields — source port, destination port, length and checksum — and no sequence number, acknowledgement, flag or window. Nothing in it could carry a handshake even if one were wanted. ## What a UDP endpoint holds instead - a **bound local port**, so arriving datagrams can be matched to a process; - a **receive queue** of datagrams waiting to be read; - nothing at all about any peer. Each arriving datagram is matched only on its destination address and port, then delivered with its source address and port attached so the application can reply. The next datagram from the same peer is processed with no memory of the first. ## What the application inherits | Concern | How TCP handles it | What a UDP application must do | |---|---|---| | Setup | three-way handshake before data | nothing — the first datagram carries data | | Peer went away | `FIN` or `RST`, or a retransmission timeout | its own idle timeout; silence is the only signal | | Who is talking | the handshake binds the connection to one peer | check each datagram's source, or ask the stack to filter | | Order and duplicates | sequence numbers | its own numbering if it cares | | Stale packets from an old session | `TIME-WAIT` on the side that closed first | tolerate them — UDP has no `TIME-WAIT` | | Nobody listening | `RST` in reply to the `SYN` | an ICMP Port Unreachable, if one comes back | Several rows deserve a closer look. **Peer liveness.** With no close exchange, a UDP receiver cannot distinguish a peer that finished, one that crashed and one whose datagrams are being dropped. Anything session-like — a game client, a media call, a telemetry agent — needs application-level identifiers and idle timeouts. **Source checks.** RFC 8085 §5: a single UDP socket can receive from many source addresses, so applications that care who sent a datagram **MUST** implement the check themselves or explicitly request that the operating system filter. The source address is also unverified: nothing like a handshake proved the sender can receive at that address. How attackers abuse that is a security topic; the protocol fact is simply that UDP never checks. **Stale datagrams.** RFC 8085 §5 points out that TCP keeps `TIME-WAIT` so delayed segments cannot be mistaken for a later connection, and "the UDP protocol does not implement such a mechanism". If one application stops and another starts receiving on the same port, the second can receive datagrams delayed in the network that were meant for the first. **Errors.** RFC 1122 §4.1.3.1 says a host SHOULD send an **ICMP Port Unreachable** when a datagram arrives for a port with no listener, and §4.1.3.3 says UDP MUST pass ICMP errors up to the application. Those errors arrive **asynchronously**, and the application must keep enough state to match them to what it sent — the discussion in §4.1.3.3 says so explicitly. ## What the network does without connection state Devices in the middle cannot watch a handshake either. RFC 8085 §3.5 describes the result: middleboxes such as NATs and firewalls create per-flow state when a packet looks like a new flow and delete it after a period with no packets. A UDP exchange that goes quiet can lose its path through such a device; the guidelines say applications SHOULD handle that failure gracefully and be able to re-establish their sessions. The binding rules themselves belong to the NAT topic. ## The upside Statelessness is also UDP's strength: 1. **No setup delay** — a one-shot query and its answer take one round trip. 2. **No per-client memory in the transport** — a server can answer vast numbers of clients it will never hear from again. 3. **One-to-many delivery** — with no two-party state machine, a datagram can be addressed to a multicast group. The interview point is to state both sides: UDP is connectionless because nothing is shared, and every guarantee that shared state would have bought becomes the application's decision.

  • How does a UDP sender ever learn that nothing is listening on the destination port?
    RFC 1122 §4.1.3.1 says the receiving host SHOULD answer with an ICMP Port Unreachable, and §4.1.3.3 says UDP MUST pass ICMP errors up to the application. The error arrives asynchronously, may be filtered along the path, and is never sent for a datagram addressed to a multicast or broadcast address — so the absence of an error proves nothing.
  • Why does the lack of a handshake matter when a UDP server decides whether to trust a datagram's source address?
    A TCP handshake shows the client can receive at the address it claims, because it must acknowledge the server's initial sequence number. UDP has no such exchange: the source address is whatever the sender wrote. Any decision based on it — access control, where to send a large reply — trusts an unverified field, and how attackers exploit that is a security topic of its own.

saying these in an interview costs you the question

  • The UDP layer keeps a table of connected clients for each server socket.
  • A UDP receiver is notified when the sending application closes its socket.
  • Connectionless means UDP cannot carry request-response exchanges.
  • UDP has verified a datagram's source address before delivering it.
  • A new application on a reused UDP port only receives datagrams sent to it.