Main Page>Table of contents>Introduction to TCP/IP>The Host-to-Host Layer Protocols>

The Host-to-Host Layer Protocols

The Host-to-Host layer’s main purpose is to shield the upper-layer applications from the complexities of the network. This layer says to the upper layer, “Just give me your data stream, with any instructions, and I’ll begin the process of getting your information ready to send.”The following sections describe the two protocols at this layer:

1. Transmission Control Protocol (TCP)
2. User Datagram Protocol (UDP)

Transmission Control Protocol (TCP)

The Transmission Control Protocol (TCP) takes large blocks of information from an application and breaks them into segments. It numbers and sequences each segment so that the destination’s TCP protocol can put the segments back into the order the application intended. After these segments are sent, TCP (on the transmitting host) waits for an acknowledgment of the receiving end’s TCP virtual circuit session, retransmitting those that aren’t acknowledged. Before a transmitting host starts to send segments down the model, the sender’s TCP protocol contacts the destination’s TCP protocol to establish a connection. What is created is known as a virtual circuit. This type of communication is called connection-oriented. During this initial handshake, the two TCP layers also agree on the amount of information that’s going to be sent before the recipient’s TCP sends back an acknowledgment. With everything agreed upon in advance, the path is paved for reliable communication to take place.

TCP is a full-duplex, connection-oriented, reliable, accurate protocol, and establishing all these terms and conditions, in addition to error checking, is no small task. TCP is very complicated and, not surprisingly, costly in terms of network overhead. Since today’s networks are much more reliable than those of yore, this added reliability is often unnecessary.

User Datagram Protocol (UDP)

Application developers can use the User Datagram Protocol (UDP) in place of TCP. UDP is the scaled-down economy model and is considered 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 also doesn’t offer all the bells and whistles of TCP, 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. There are some situations where it would definitely be wise for application developers to opt for UDP rather than TCP. SNMP monitors the network, sending intermittent messages and a fairly steady flow of status updates and alerts, especially when running on a large network. The cost in overhead to establish, maintain, and close a TCP connection for each one of those little messages would reduce what would be an otherwise healthy, efficient network to a dammed-up bog in no time. Another circumstance calling for UDP over TCP is when the matter of reliability is already accomplished at the Process/Application layer. Network File System (NFS) handles its own reliability issues, making the use of TCP both impractical and redundant. However, the application developer decides whether to use UDP or TCP, not the user who wants to transfer data faster.

UDP receives upper-layer blocks of information, instead of data streams as TCP does, and breaks them into segments. Like TCP, each UDP segment is given a number for reassembly into the intended block at the destination. However, UDP does not sequence the segments and does not care in which order the segments arrive at the destination. At least it numbers them, though. But after that, 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. It is, therefore, 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 developera choice when running the Internet Protocol stack: TCP for reliabilityor UDP for faster transfers.

Key Concepts of Host-to-Host Protocols

Since we have seen both a connection-oriented (TCP) and connectionless (UDP) protocol in action, it would be good to summarize the two here. The following list highlights some of the key concepts that you should keep in mind regarding these two protocols.

A telephone analogy might help you understand how TCP works. Most of us know that before you speak to someone on a phone, you must first establish a connection with that other person—wherever they might be. This is like a virtual circuit with the TCP protocol. If you were giving someone important information during your conversation, you might ask, “Did you get that?” A query like that is similar to a TCP acknowledgment. From time to time, for various reasons, people also ask, “Are you still there?” They end their conversations with a “goodbye” of some kind, putting closure on the phone call. TCP also performs these types of functions. Alternately, using UDP is like sending a postcard. To do that, you don’t need to contact the other party first. You simply write your message, address the postcard, and mail it. This is analogous to UDP’s connectionless orientation. Since the message on the postcard is probably not a matter of life or death, you don’t need an acknowledgment of its receipt. Similarly, UDP does not involve acknowledgments.