UDP

In 1980, David P. Reed was working on a seemingly simple problem: how to transmit data between computers without all the complexity that TCP already imposed? The Internet architecture was taking shape around the TCP/IP suite, but certain applications called for something more direct, faster. Reed then conceived UDP, the User Datagram Protocol, which would become one of the most enduring protocols on the Internet.

Where TCP built solid connections, verified each packet, and guaranteed the order of data arrival, UDP deliberately chose the opposite. No persistent connection, no delivery guarantees, no packet ordering control. This minimalist approach is reflected in RFC 768, which defines the protocol: three short pages suffice where other specifications stretch across hundreds of pages.

This brevity was not negligence. Reed and his colleagues understood that the Internet would need two types of tools: sophisticated protocols like TCP for critical data, and lightweight mechanisms like UDP for other uses. The first service to truly exploit this philosophy was the Internet Name Service, the ancestor of DNS. When a computer requests the IP address of a website, it doesn't need to establish a complex connection; it sends its query and waits for the response. If the response is lost, it asks again. Simple, straightforward.

DNS still uses this approach, and for good reason—a server handles thousands of queries per second without maintaining state for each client. This resource economy proves invaluable when you consider that a root DNS server can receive millions of queries per hour.

The history of UDP took an unexpected turn with the emergence of multimedia communications. When Voice over IP took its first steps in the 1990s, developers discovered that UDP perfectly matched their needs. In a phone conversation, it's better to lose a few milliseconds of audio than to wait for a missing packet to be retransmitted. User experience takes precedence over technical perfection. This logic naturally extended to videoconferencing, then to online gaming. In an online shooter game, if the information that a player has fired arrives late, it's useless. Developers handle these temporal issues themselves with UDP, according to their application's specifics.

UDP's elegance lies in this flexibility. The protocol doesn't dictate how to handle errors or packet ordering; it leaves that responsibility to applications. Some games retransmit critical information multiple times to ensure reception. Others simply ignore lost packets and focus on the most recent data.

This approach has inspired new innovations. DCCP adds congestion control to UDP to avoid overloading the network, and DTLS brings cryptographic security. These protocols show that UDP serves as a stable foundation for building specialized solutions.

Performance measurements confirm Reed's initial intuitions. A study conducted between 2004 and 2014 on a transpacific link between Japan and the United States revealed variations in average IP packet size. UDP, generating less control traffic than TCP, contributes to more efficient bandwidth usage.

The emergence of sensor networks has given UDP new life. These devices, often battery-powered, periodically transmit temperature, humidity, or position measurements. They don't need TCP's robustness; they prefer to conserve their energy by simply transmitting their data without establishing a complex connection.

Cloud computing and microservices have rediscovered UDP's virtues. When an application decomposed into dozens of services must communicate quickly, UDP offers minimal latency. Netflix thus uses UDP for certain internal communications, Spotify for synchronizing playlists between devices.

The evolution toward the UDP-Lite variant demonstrates this adaptability, tolerating certain errors in packet headers, useful in wireless communications where a few corrupted bits don't justify rejecting an entire packet.

Forty-three years after its creation, UDP continues to thrive on the Internet. Its longevity stems from a simple principle: rather than trying to solve all problems, it solves a few of them perfectly well. This specialization has allowed it to endure through the ages, from early university networks to modern data centers. This constancy makes it one of the discrete but indispensable pillars of the Internet.