Udp
The User Datagram Protocol (UDP) is the minimalist transport-layer protocol that sends independent messages, called datagrams, from one program to another with no connection setup, no delivery guarantee and no ordering. It adds only two things to raw IP: port numbers, so a datagram reaches the right program on a machine, and an optional checksum to detect corruption.
UDP was defined in RFC 768 in 1980, a document only about three pages long, and its brevity is the point. Its header is a mere eight bytes: source port, destination port, length and checksum, each two bytes. There is no handshake, no sequence number, no acknowledgment and no retransmission. A sender simply hands a datagram to the network, and it either arrives whole or does not arrive at all; UDP preserves message boundaries, so one send produces exactly one receive, in contrast to the byte stream of TCP. With IPv4, the largest possible payload is 65,507 bytes, although in practice datagrams are kept near the path's MTU, roughly 1,400 bytes, to avoid fragmentation.
Skipping guarantees makes UDP cheap and fast to start, which suits traffic where freshness matters more than completeness or where one exchange is tiny. A DNS lookup is a single question and a single answer, so a three-way handshake would cost more than the work itself; DHCP and NTP likewise use UDP. Live voice and video calls, online games and streaming telemetry prefer UDP because a retransmitted packet arrives too late to be useful, and waiting for it would stall everything behind it. Applications in these domains build only the reliability they need, for instance a jitter buffer or forward error correction, rather than paying for strict ordering.
UDP also serves as a foundation for new transports, because it passes through the existing Internet and can be implemented in user space. QUIC, standardized as RFC 9000 in 2021, runs over UDP and rebuilds reliability, congestion control, multiplexed streams and TLS 1.3 encryption itself, and it carries HTTP/3. Placing the new protocol in user space let browsers and servers deploy it without waiting for operating-system and middlebox upgrades, which had long frozen the evolution of TCP. WebRTC, used by browser video calls, similarly rides on UDP.
The usual misconception is that UDP is simply a worse or unsafe version of TCP, or that it is always faster. It is a different trade: for bulk file transfer, TCP's reliable delivery is exactly what is wanted, and a UDP program that must retransmit and order data ends up reimplementing TCP, often badly and without congestion control that protects the network. Unthrottled UDP sources can flood links, which is why well-behaved designs include their own rate control. UDP's lack of a handshake also allows source addresses to be spoofed easily, enabling reflection and amplification attacks in which a small forged request to an open DNS or NTP server produces a large reply sent at a victim. Firewalls and corporate networks also sometimes restrict UDP, so applications often need a TCP fallback.
For programmers, UDP appears through datagram sockets, and its behavior differs in ways that matter. A receiving call returns one whole datagram, a buffer too small silently truncates it, and a successful send says nothing about arrival. Multicast and broadcast, used for local service discovery and some streaming and financial data feeds, are possible only with UDP-style delivery. In machine-learning and high-performance computing, some low-latency interconnects, such as RDMA over Converged Ethernet in its routable version, encapsulate traffic in UDP, showing how a 1980 design still carries modern workloads.
Read UDP as a postcard service: no connection, no receipt, no promise of order, just a port-addressed message sent as fast as possible, leaving the application free to decide how much reliability, if any, is worth paying for.