Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Lower-Layer (Interface, Internet and Transport) Protocols (OSI Layers 2, 3 and 4)       9  TCP/IP Transport Layer Protocols            9  Transmission Control Protocol (TCP) and User Datagram Protocol (UDP)                 9  TCP/IP User Datagram Protocol (UDP)

TCP/IP User Datagram Protocol (UDP) 1 UDP Operation

I suppose the “sibling rivalry” analogy I drew in the introduction to this section may be a little bit silly. I highly doubt that protocols lie awake at night worrying about how much we use them. J However, it's interesting to discover just how important the User Datagram Protocol (UDP) really is, given how little attention it gets compared to the Transmission Control Protocol (TCP). In fact, in true older-sibling, spotlight-stealing fashion, we can't even really understand the history of UDP without first discussing TCP.

In the topic that describes the history of TCP/IP, I explained that very early on in the development of the protocol suite, there was only one protocol that handled the functions now performed by both IP and TCP. This protocol, itself called TCP, provided network-layer connectivity like IP, and also established connections, provided reliability and took care of the typical transport-layer “quality” requirements as flow control and retransmission handling that we associate with modern TCP.

It didn’t take long before the developers of the fledgling combined protocol quickly realized that mixing these functions together was a mistake. While most conventional applications needed the classic transport-layer reliability functions, some did not. These features introduced overhead, which would have to be endured even by the applications where reliability features were not needed at all. Worse, there were some applications where the features were not only of no value, but actually a detriment, since even the small amount of lost performance due to the overhead would be a problem.

The solution was to separate the original protocol into IP and TCP. Basic internetworking was to be done by IP, and the reliability features by TCP. This paved the way for the creation of an alternative transport-layer protocol for applications that didn't want or need the features provided by TCP. This, of course, is the User Datagram Protocol (UDP).

There are two main attributes that come up again and again when describing UDP: simple and fast. It is a simple protocol that uses a very straight-forward messaging structure that is similar to the message format used by many other TCP/IP protocols (in contrast to the more complex data structures—streams and segments—used by TCP). In fact, when you boil it down, the only real goal of the protocol is to serve as an interface between networking application processes running at the higher layers, and the internetworking capabilities of IP. Like TCP, UDP layers on top of IP a method of transport-layer addressing (and hence, process identification) through the use of UDP port numbers. It does include an optional checksum capability for error-detection, but adds virtually no other functionality.

In fact, the best way to see for yourself the simplicity of UDP is to look at the standards that define it. Or rather, I should say standard in the singular, because there is only one. UDP was defined in RFC 768, User Datagram Protocol, in 1980. This document is all of three pages in length, and has never needed to be revised.

UDP is a fast protocol specifically because it doesn't have all the bells and whistles of TCP. This makes it unsuitable for use by many, if not most, typical networking applications. But for some applications, this is exactly what they want from a transport layer protocol: something that takes their data and quickly shuffles it down to the IP layer with a minimum of fuss. In choosing to use UDP, the application writer takes it upon himself or herself to take care of issues such as reliability and retransmissions, if they are needed. This can be a recipe for success or failure, depending on the application and how carefully UDP is used.

TCP/IP User Datagram Protocol (UDP) 1 UDP Operation