UDP Header
UDP Header
• UDP Ports
T he User Datagram Protocol (UDP) as described in RFC 768 offers fast, unreliable
delivery of messages between applications running on remote hosts. UDP maps to
the OSI Transport and DoD Host-to-Host layers, and is an alternative to the slow but
reliable TCP protocol. Figure 9.1 maps UDP to the OSI and DoD reference models.
242 TCP/IP PRIMER PLUS
Internet Network
Data Link
Network
Access Physical
UDP Operation
Like TCP, UDP receives a stream of data (messages) from upper-layer applications or processes
identified by ports. UDP at the Transport layer breaks down these streams of data into seg-
ments and hands them down to IP at the Network layer, packaging them as datagrams for
delivery to the host across the internetwork. Protocol type 17 identifies UDP within the IP
header. Figure 9.2 shows UDP identified in an IP header.
FIGURE 9.2
Notice that protocol type
17 identifies UDP within
an IP header.
Unlike TCP, UDP does not set up sessions. As a connectionless protocol UDP does not
sequence sent data or acknowledge received data. UDP assumes that some other protocol
Chapter 9 • USER DATAGRAM PROTOCOL (UDP) 243
(usually an upper-layer protocol) will track whether the sent data has reached the destination.
If the data does not reach its destination, UDP also assumes the upper-layer protocol will rec-
ognize this and request a retransmission of the data. Because UDP does not establish a connec-
tion, it has no logical circuit to establish before transmission. Because it has no logical
connection between end hosts, it has no management responsibilities for maintaining a con-
nection.
UDP does not fragment; it only identifies the source and destination port. Unlike TCP,
which breaks upper-layer applications’ bit streams into segments, UDP simply provides a
bi-directional pipe between communicating devices. UDP relies on IP for fragmentation and
reassembly.
UDP operates on a very simple basis—best effort delivery. Whereas TCP guarantees the deliv-
ery of data by sequencing and acknowledging every single byte sent or received, UDP offers
only best effort delivery, relying on other layers to detect and recover lost or missing data-
grams. However, despite not being able to guarantee delivery of packets, UDP has one advan-
tage over TCP—speed. UDP’s simplistic nature drastically reduces the overhead involved with
transmitting data, making it a much faster, yet unreliable alternative to TCP.
UDP Applications
Application vendors can implement TCP or UDP at the Transport layer depending on the type
of service the application requires. For example, most printing applications run on top of TCP
because most users want to guarantee a successful print job, rather than hoping it prints. Two
upper-layer protocols, FTP (File Transfer Protocol) and TFTP (Trivial File Transfer Protocol)
provide similar functions but implement different Transport layer services. Both FTP and TFTP
provide file transfer capabilities between hosts. FTP utilizes the services of TCP at the
Transport layer to guarantee the successful completion of file transfers, detecting and correct-
ing any lost, missing, or duplicated datagrams. FTP usually is used for the transfer of critical
data.
TFTP provides the same file transfer services as FTP, except that it utilizes UDP for faster deliv-
ery and less overhead. This method of delivery has the drawback of being less reliable; how-
ever, as the name implies (Trivial File Transfer Protocol), TFTP is designed for quick delivery
of small files (trivial files) between hosts. As you can see, vendors can choose which Transport
layer protocol to implement depending on what type of service is more critical—speed or reli-
ability. TFTP assumes the following:
• Stability of the network infrastructure
• Only trivial delivery errors (if any) may occur
We will discuss FTP in more detail in Chapter 12, “File Transfer Protocol (FTP),” and TFTP in
Chapter 16, “Trivial File Transfer Protocol (TFTP).”
244 TCP/IP PRIMER PLUS
UDP Ports
As a connectionless protocol UDP does not sequence or acknowledge data. It simply identifies
the sending (source) and receiving (destination) ports within the UDP header and relies on IP
to package and deliver the information. Table 9.1 shows a list of common UDP ports (see
Appendix C, “TCP/UDP Port Numbers,” for a complete list of UDP Ports).
UDP Header
In Chapter 7, “Transport/Host-to-Host Layer” we discussed the fields within the TCP header
and their functions. TCP headers vary in length, depending on the TCP options in use, but
always have a minimum of 20 bytes. However, the connectionless UDP contains minimal
information in its header.
By comparison, UDP headers are only 8 bytes in length. Figure 9.3 gives an example of a UDP
header as defined in RFC 768. Figure 9.4 shows a tangible UDP header as it actually appears
during implementation.
Note
Like TCP, UDP must identify the source and destination ports. Unlike TCP, UDP does not include
sequencing or acknowledgements. UDP uses a checksum in the header, which only detects damaged
frames.
FIGURE 9.3
Source Port Destination Port
This figure merely shows
the format of a UDP Length Checksum
FIGURE 9.4
As you can see, a UDP
header does not contain
much information.
Source Port
The first field within the UDP header identifies the source port. This 2-byte field, similar to the
TCP source port field, identifies the sending host’s upper-layer application or process. The
value of this port depends on whether the sending host is a client process or a server process.
If it is a client process, the sending host chooses this port value within the range of 1,024 to
65,535. If this is a server process, such as a well-known application sending a request or
responding to a client request, the value ranges between 1 and 1,023.
Destination Port
The second field in the UDP header, the destination port, has a 2-byte field. Similar to the TCP
destination port field, it identifies the receiving host’s upper-layer application or process. The
value of this port depends on whether the receiving host is a client process or a server process.
If it is a client process, this port value varies within the range of 1,024 to 65,535. If this is a
server process, such as a well-known application, the value ranges between 1 and 1,023.
Length Field
The length field, the third field within the UDP header, specifies in bytes how much data is
contained within this datagram. This value includes the UDP header and the data following
(upper-layer protocols and information). The length field will be a minimum of 8 bytes, which
is the total value of the fields within this header plus any upper-layer data and information.
246 TCP/IP PRIMER PLUS
Checksum
Although the connectionless UDP has no mechanism for detecting and correcting lost, miss-
ing, or duplicate frames, it does have a minimal method of detecting damaged frames. The 2-
byte checksum, the fourth field within the UDP header, guarantees that the bits have not been
damaged during transit. This does not correct damage frames; it simply detects and trashes
them.
The sending host UDP process initially performs the checksum, known as a CRC (Cyclic
Redundancy Check), placing the resulting value within the UDP header. At the destination, the
receiving host’s UDP process performs the same calculation to verify the contents of the
header. If the CRC value finds the frames invalid, the receiving host assumes a transmission
error has occurred and trashes the datagram.
The checksum validates the following:
• The UDP header
• The upper-layer data
• Information contained within a UDP pseudo header
The UDP pseudo header contains 12 bytes for the checksum computation within the UDP
datagram. Note that the pseudo header contains certain fields from the IP header. However,
the UDP pseudo header does not actually appear in the UDP header. UDP uses the pseudo
header to ensure that data has arrived at the correct destination. Figure 9.5 shows an example
of a UDP pseudo header.
FIGURE 9.5
IP Source Address
A UDP pseudo header
IP Destination Address
enables UDP to make
sure IP has not delivered Zero IP Protocol UDP Length
or accepted a datagram to
the wrong location,
whether an incorrect host
or upper layer.
The UDP pseudo header has its name because UDP does not actually include this information
within its header; instead it keeps track of this information to guard against misrouted data-
grams. The host stores this information in its memory and UDP accesses it for reference pur-
poses.
Summary
RFC 768 defines UDP. UDP offers fast, unreliable delivery of messages between applications
running on remote hosts. UDP receives a stream of data (messages) from upper-layer applica-
tions or processes. UDP at the Transport layer breaks down these streams of data into seg-
ments and hands them down to IP at the Network layer, packaging them as datagrams for
delivery to the host across the internetwork.
As a connectionless protocol UDP does not sequence sent data or acknowledge received data.
UDP relies on other protocols to track whether sent data reaches its destination. Because UDP
has no logical connection, this also means that it has no management responsibilities for main-
taining a connection. UDP operates on a best effort delivery; although it cannot guarantee
delivery of packets, the simplistic nature of UDP drastically reduces overhead and provides an
alternative to the slower TCP. Application vendors can implement TCP or UDP at the
Transport layer, depending on the type of service the application requires.
Review Questions
1. What RFC defines UDP?
2. What does UDP provide for applications running on remote hosts?
3. What protocol type identifies UDP in the IP header?
4. What relationship does UDP have with sequencing and acknowledging the receipt of
sent data?
5. During UDP operation of transferring data, what does this protocol assume?
6. What management responsibilities does UDP have with maintaining a connection?
7. What does UDP offer that TCP doesn’t?
8. What mechanism does UDP use to check only for damaged frames?
9. What three things does the checksum validate?
10. The UDP pseudo header contains what information?