Connection versus connectionless communication

The idea of connectionless communication might seem like an oxymoron at first. How could two entities possibly communicate if they haven't connected first? How would one even know that the other exists to communicate with?

The underlying principle is that in a connection-based communication protocol, both hosts must first establish a line of communication before the transmission of any application-specific data can begin. The handshake sequence in TCP is the most obvious example of this. There is a complete round-trip of sent/received messages that must succeed before the connection is considered established, and data can be transmitted between hosts. That established line of communication is the 'connection' in this context. It consumes time and bandwidth, but provides reliability and error correction, and in almost all cases, the value of the reliability and error correction is worth far more than the costs incurred.

Meanwhile, in connectionless communication, data could be transmitted, and the communication terminated, without even a single complete round-trip from the client to the server, and back to the client again. The packet has sufficient information in its own headers to be properly routed to a listening host. Provided that host has no follow-up to the initial request, that communication will stop with only a one-way packet delivery. The low-latency of this transmission pattern could be a major benefit in certain application contexts.

There's still so much more to explore with both of these protocols, going forward, but that is the concern of a later chapter in this book. For now though, I hope this makes it clear why the transport layer and its protocols serve such a major role in designing and implementing high-performance and highly-reliable network software.