User Datagram Protocol (UDP)

The User Datagram Protocol, or UDP, is the other most commonly used Transport layer protocol found within the Internet. While TCP is designed to provide connection-oriented delivery of packets, UDP implements a connectionless or unguaranteed delivery mechanism that is suitable for a number of upper layer applications. For some applications, the overhead of TCP, such as handshaking, is not required and for these, UDP is best suited.

A comparison between TCP and UDP can be drawn from the world of cellular phones. TCP is similar in nature to a full telephone conversation, whereby you establish a connection to the receiving station by dialing their number, hold a conversation with them using verbal interaction and acknowledgments, and finally terminate the call. UDP is much more akin to SMS or text messaging, whereby you write a message and send it without receiving any acknowledgment of its delivery from anything other than a local call access point.

UDP does share some common characteristics with TCP, as it does implement source and destination ports, to identify application sockets, and a checksum to verify the correct delivery of the layer 4 datagram.

A Simple UDP Data Flow

Let's consider our two example machines again, but this time interacting using UDP rather than TCP. The Domain Name System, or DNS, is one of the most commonly implemented UDP-based applications ”our example will consider a client (10.10.10.10) requesting a name resolution from a DNS server (20.20.20.20).

It is important to note that UDP traffic can be both bidirectional, such as the request-response nature of DNS queries, and unidirectional, such as alerts raised through the Simple Network Management Protocol (SNMP). In both instances, the nature of the application determines whether a response is required; UDP simply provides a datagram format for the data between the two end points.

The Request

The first thing you will notice in Figure 2-11 is that the structure of the UDP header is far simpler than that used by TCP. There are only four fields used within the UDP header, to indicate the source and destination ports, the header length, and the checksum. It is clear from this that many of the techniques used by TCP are simply not present in UDP, such as sequencing, handshaking, and flow control.

The Response

As DNS is a bidirectional, request-response application, the frame shown in Figure 2-11 will yield an answer from the DNS server, also carried using UDP. Figure 2-12 shows the response. Note that the source and destination ports are reversed as with TCP, as the client sending the request will be listening and expecting an answer on port 1763.

Figure 2-11 A UDP-based DNS query.

 Internet Protocol Headers     Version: 4     Time to live: 249     Protocol: UDP (0x11)     Header checksum: 0xc8de (correct)     Source: 20.20.20.20     Destination: 10.10.10.10 Transmission Control Protocol Headers  Source port: domain (53)   Destination port: 1763 (1763)   Length: 276   Checksum: 0x04bc (correct)  Domain Name System (response)     Answers         www.foo.com: type A, class inet, addr 1.2.3.4             Name: www.foo.com             Type: Host address             Class: inet             Time to live: 10 minutes             Data length: 4             Addr: 1.2.3.4 

This is again a very brief overview of the UDP protocol. A more detailed description is available in RFC 768, available on the IETF Web site.