Key Concepts of Host-to-Host Protocols – CCNA Course

In this article of Internet Layer, we’ll see some of the key concepts of Host-to-Host Protocols under our CCNA Course.

If you want to read details about Process/Application Layer or Host-to-Host Protocols layers before going further ahead, you can do that.

Since we have seen, in previous articles, both a connection-oriented (TCP) and connectionless (UDP) protocol in action, it would be good to summarize the two here.

The following table highlights some of the key concepts that you should keep in mind regarding these two protocols. You should memorize this table.

A telephone analogy could really 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 are.

This is like a virtual circuit with the TCP protocol. If you were giving someone important information during your conversation, you might say, “You know?” or ask, “Did you get that?” saying something like this is a lot like a TCP acknowledgment it’s designed to get you verification.

From time to time (especially on cell phones), 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.

Alternatively, 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.

Let’s take a look at another figure given below, one that includes TCP, UDP, and the applications associcates to each protocol.

Port Numbers

TCP and UDP must use port numbers to communicate with the upper layers because they’re what keep track of different conversations crossing the network simultaneously.

Originating source port numbers are dynamically assigned by the source host and will equal some number starting at 1024. 1023 and below are defined in RFC 3232 (or just see www.iana.org), which discusses what are called well-known port numbers.

Virtual circuits that don’t use an application with a well-known port number are assigned port numbers randomly from a specific range instead. These port numbers identify the source and destination application or process in the TCP segment.

The following figure illustrates how both TCP and UDP use port numbers.

The different port numbers that can be used are explained next:

• Numbers below 1024 are considered well-known port numbers and are defined in RFC 3232.
• Numbers 1024 and above are used by the upper layers to set up sessions with other hosts and by TCP to use as source and destination addresses in the TCP segment.

In the following sections, we’ll take a look at an analyzer output showing a TCP session.

TCP session: Source Port

The following listing shows a TCP session captured with Omni Peek analyzer software

Notice that the source host makes up the source port, which in this case is 5973. The destination port is 23, which is used to tell the receiving host the purpose of the intended connection (Telnet).

By looking at this session, you can see that the source host makes up the source port by using numbers from 1024 to 65535. But why does the source make up a port number?

To differentiate between sessions with different hosts, my friend. How would a server know where information is coming from if it didn’t have a different number from a sending host?

TCP and the upper layers don’t use hardware and logical addresses to understand the sending host’s address as the Data link and Network layer protocols do. Instead, they use port numbers. And it’s easy to imagine the receiving host getting thoroughly confused if all the hosts used the same source port numbers to get to FTP!

TCP Session: Destination Port

You’ll sometimes look at an analyzer and see that the source port is above 1024 and the destination port is a well-known port, as shown in the following trace:

And sure enough, the source port is over 1024, but the destination port is 80, or HTTP service. The server, or receiving host, will change the destination port if it needs to.

In the preceding trace, a “syn” packet is sent to the destination device. The syn sequence is what’s telling the remote destination device that it wants to create a session.

TCP Session: Syn Packet Acknowledgment

The next trace shows an acknowledgment to the syn packet:

Notice that the Ack is valid, which means that the source port was accepted and the device agreed to create a virtual circuit with the originating host.

Again here again, you can see that the response from the server shows the source is 80 and the destination is the 1144 sent from the originating host all’s well.

The table below gives you a list of the typical applications used in the TCP/IP suite, their well-known port numbers, and the Transport layer protocols used by each application or process.

Notice that DNS uses both TCP and UDP. Whether it opts for one or the other depends on what it’s trying to do.