Transport Layer, Unreliable Connections

One of the issues of connection-oriented services is that they must always go through a three-way handshake before you can transfer data. In some instances, like file transfers, this makes sense, because you want to make sure that all data for the file is transferred successfully. However, in other cases, when you want to send only one piece of information and get a reply back, going through the three-way handshake process adds additional
overhead that isn’t necessary.

A DNS query is a good example where using a connection-oriented service doesn’t make sense. With a DNS query, a device is trying to resolve a fully qualified domain name to an IP address. The device sends the single query to a DNS server and waits for the server’s response.

In this process, only two messages are generated: the client’s query and the server’s response. Because of the minimal amount of information shared between these two devices, it makes no sense to establish a reliable connection first before sending the query. Instead, the device should just send its information and wait for a response.

If a response doesn’t come back, the application can send the information again or the user can get involved. Again, with DNS, you can configure two DNS servers in the Microsoft Windows operating system. If you don’t get a reply from the first server, the application can use the second configured server.

Because no “connection” is built up front, this type of connection is referred to as a connectionless service. The TCP/IP protocol stack uses the User Datagram Protocol (UDP) to provide unreliable connections.