As we have seen in our exploration of the User Datagram Protocol, UDP contains very little functionality. With the exception of the important addressing capability that UDP ports represent, using UDP is very much like using IP directly. This means UDP has most of the same disadvantages that IP has. It doesn't establish a lasting connection between devices; it doesn't acknowledge received data or retransmit lost messages, and it certainly doesn't concern itself with esoterics such as flow control and congestion management.

The lack of these features makes UDP simply unsuitable for the majority of “classical” networking applications. These usually need to be able to establish a connection, so the two devices can exchange data back and forth. Many also need the ability to occasionally or even regularly send very large amounts of data that must be received intact for it to be of value. For example, consider a message transfer protocol like HTTP. If only part of a Web page gets from a server back to a Web browser, it's useless. HTTP and other file and message transfer protocols like it need the capabilities we mentioned just above.

I have read about problems that have occurred in the past in applications using UDP. Sometimes programmers don't realize how little UDP does, and that it leaves the application responsible for handling all the potential vagaries of an internetworking environment. Someone writing a UDP-based application must always keep in mind that no assumptions can be made about how or even whether any message will be received by its destination, and must plan accordingly. Insufficient testing can lead to disaster in worst-case scenarios on a larger internet and especially, the Internet.