If you were to compare
User Datagram Protocol (UDP) with TCP,
the former is basically the scaled-down economy model that’s sometimes referred to as a thin protocol.
Like a thin person on a park bench, a thin protocol doesn’t take up a lot of
room—or in this case, much bandwidth on a network.
UDP doesn’t offer all the bells
and whistles of TCP either, but it does do a fabulous job of transporting
information that doesn’t require reliable delivery—and it does so using far
fewer network resources. (UDP is covered thoroughly in Request for Comments
768.)
There are some situations in
which it would definitely be wise for developers to opt for UDP rather than
TCP. One circumstance is when reliability is already handled at the
Process/Application layer. Network File System (NFS) handles its own
reliability issues, making the use of TCP both impractical and redundant. But
ultimately, it’s up to the application developer to decide whether to use UDP
or TCP, not the user who wants to transfer data faster.
UDP does not sequence the segments and does not care in which order the
segments arrive at the destination. Rather, UDP sends the segments off and
forgets about them. It doesn’t follow through, check up on them, or even allow
for an acknowledgment of safe arrival—complete abandonment. Because of this, it’s
referred to as an unreliable protocol. This does not mean that UDP is
ineffective, only that it doesn’t handle issues of reliability.
Further, UDP doesn’t create a
virtual circuit, nor does it contact the destination before delivering information
to it. Because of this, it’s also considered a connectionless
protocol.
Since UDP assumes that the application will use its own reliability method, it
doesn’t use any. This gives an
application developer a choice
when running the Internet Protocol stack: TCP for reliability or UDP for faster
transfers.
So, it is important to remember
how this works because if the segments arrive out of order (very common in IP
networks), they’ll just be passed
up to the next OSI (DoD) layer
in whatever order they’re received, possibly resulting in some seriously
garbled data. On the other hand, TCP
sequences the segments so they get put back together in exactly
the right order—something UDP just can’t do..
UDP Segment Format
Source port Port number
of the application on the host sending the data
Destination port Port number
of the application requested on the destination host
Length Length of
UDP header and UDP data
Checksum Checksum of
both the UDP header and UDP data fields
Data Upper-layer
data
UDP, like TCP, doesn’t trust
the lower layers and runs its own CRC. Remember that the Frame Check Sequence
(FCS) is the field that houses
the CRC, which is why you can see the FCS information.