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

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.

Sequenced Unsequenced
Reliable Unreliable
Connection-oriented Connectionless
Virtual circuit Low overhead
Acknowledgment No acknowledgment
Windowing flow control No windowing or flow control

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

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

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

TCP Transport Control Protocol
Source Port 5973
Destination port 23
Sequence Number 1456389907
Ack Number 1242056456
Offset 5
Reserved %000000
Code %011000
Ack is valid  
Push Request  
Window 61320
Checksum 0x61a6
Urgent Pointer 0
No TCP Options  
TCP Data Area vL.5.+.5.+.5.+.5  76  4c  19  35  11  2b  19  35  11  2b  35  +.  11  2b  19
Frame Check Sequence 0x0d0000f

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:

TCP Transport Control Protocol
Source Port 1144
Destination port 80 World Wide Web HTTP
Sequence Number 9356570
Ack Number 0
Offset 7
Reserved %000000
Code %000010
Synch Sequence  
Window 8192
Checksum 0x57E7
Urgent Pointer 0
TCP Options  
Option Type 2 Maximum Segment Size
Length 4
MSS 536
Option Type 1 No Operation
Option Type 1 No Operation
Option Type 4
Length 2
Opt Value  
No more HTTP data  
Frame Check Sequence 0x43697363

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:

TCP Transport Control Protocol
Source Port 1144
Destination port 80 World Wide Web HTTP
Sequence Number 2873580788
Ack Number 9356571
Offset 6
Reserved %000000
Code %010010
Ack is valid  
Synch Sequence  
Window 8576
Checksum 0x5F85
Urgent Pointer 0
TCP Options  
Option Type 2 Maximum Segment Size
Length 4
MSS 1460
No more HTTP Data  
Frame Check Sequence 0x6E203132

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.

Telnet 23 SNMP 161
HTTP 80 DNS 53
FTP 21  
DNS 53