TCP/IP knowledge point: host-to-host layer protocol

Host-to-Host Layer Protocol

The main function of the host-to-host layer is to hide the complexity of the network from the upper layer applications, it tells the upper layer: "Just give me your data and instructions, I will process your information and prepare it for sending.

The next few sections will introduce two protocols at this layer:

• Transmission Control Protocol (TCP);
• User Datagram Protocol (UDP).

Additionally, we'll introduce some important host-to-host protocol concepts, as well as port numbers.

Note: Don't forget, this is still considered Layer 4, which allows for acknowledgment, sequencing, and flow control, and Cisco likes this.

1. TCP

TCP (Transmission Control Protocol) receives large blocks of data from applications and divides them into segments. It numbers each segment so that the receiving host's TCP stack can arrange the segments in the order the application wants. After sending a segment, the sending host's TCP waits for an acknowledgment from the receiving TCP and retransmits unacknowledged segments.

Before the sending host begins to send data segments down the layered model, the sender's TCP stack contacts the destination host's TCP stack to establish a connection. They create a virtual circuit, and this type of communication is considered connection-oriented. During this initial handshake, the two TCP stacks will also agree on the amount of information that will be sent before the receiving TCP sends back an acknowledgment. By agreeing on everything in advance, the way is paved for reliable communication.

TCP is a reliable, precise protocol that is full-duplex and connection-oriented, but requires agreement on all terms and conditions and error checking, which is no small task. It's no surprise that TCP is complex and has a lot of network overhead. Given that today's networks are much more reliable than they ever were, this extra reliability is often unnecessary. Most programmers use TCP because it eliminates a lot of programming work, but real-time video and VoIP use UDP because they can't afford the extra overhead.

●Format of TCP data segment

Given that the upper layers only send data streams to the transport layer protocols, the following describes how TCP segments the data stream and prepares the data for the Internet layer. The Internet layer receives the data segments and routes them as packets in the internetwork. The segments are then handed to the host-to-host layer protocol of the receiving host, which reconstructs the data stream and hands it to the upper layer application or protocol.

Figure 3-4 illustrates the format of a TCP data segment, listing the various fields in the TCP header.

The TCP header is 20 bytes long (24 bytes when options are included), and you must understand every field in the TCP segment.

• Source Port The port number of the application on the sending host (port numbers are explained later in this section).
• Destination Port The port number of the application on the destination host.
• Sequence number - a number that TCP uses to put data in the correct order (called sorting) and to retransmit lost or damaged data.
• The acknowledgment number TCP expects to receive the next data segment.
• Header Length The length of the TCP header, in 32-bit words. It indicates the start of the data. The length of the TCP header is an integer multiple of 32 bits, even when options are included.
• Reserved is always set to zero.
• The coded bits/flags are used for control functions that establish and terminate sessions.
• Window Size The window size the sender is willing to accept, in bytes.
• Checksum CRC (Cyclic Redundancy Check), because TCP does not trust the lower layers, so all data is checked. CRC checks the header and data fields.
• Urgent This field is valid only if the Urgent Pointer field in the Encoded bit is set. If the Urgent Pointer is set, this field indicates the offset of the beginning of the non-urgent data relative to the current sequence number, in bytes.
• The length of an option is either 0 or an integer multiple of 32 bits. That is, when there are no options, the length is 0. However, if the length of the field is not an integer multiple of 32 bits when options are included, it must be padded with zeros to ensure that the length of the field is an integer multiple of 32 bits.
• The data is passed to the TCP protocol of the transport layer, including the upper layer header.

Here is a TCP segment copied from a network analyzer:

Did you notice the various items in the data segment discussed earlier? From the number of fields contained in the header, it can be seen that TCP has a large overhead. To save overhead, application developers may prioritize efficiency rather than reliability, so as an alternative, UDP is also defined at the transport layer.

2. UDP

If you compare UDP to TCP, you'll see that UDP is basically a stripped-down version, sometimes called a thin protocol. Like a thin man on a park bench, a thin protocol doesn't take up much space—it doesn't take up much bandwidth on a network. UDP doesn't offer all the features of TCP, but it does a pretty good job of delivering information that doesn't need to be delivered reliably, and it does so with fewer network resources. (RFC 768 describes UDP in detail.)

There are cases where it is absolutely wise for a developer to choose UDP over TCP, such as when reliability is already ensured at the process/application layer. NFS (Network File System) handles its own reliability issues, which makes the use of TCP both impractical and redundant. But in the final analysis, the choice of using UDP or TCP is up to the application developer, not the user who wants to transfer data faster.

UDP does not order segments, nor does it care about the order in which they arrive at their destination. Instead, UDP sends the segments out and forgets about them. It does not inspect the segments, nor does it support confirmations that they arrived safely, but is completely hands-off. For this reason, UDP is called an unreliable protocol. This does not mean that UDP is inefficient, it just means that it does not handle reliability issues at all.

In addition, UDP does not establish a virtual circuit, nor does it contact the receiver before sending information. Therefore, it is also called a connectionless protocol.

Because it is assumed that applications will use their own reliability methods, UDP does not. This gives application developers the choice when developing the Internet protocol stack: use TCP to ensure reliability, or use UDP to increase transmission speed.

Therefore, it is crucial to keep in mind how UDP works, because if the data segments arrive out of order (which is common in IP networks), they will be passed to the next layer of the OSI (DoD) model in the order they were received, which can make the data extremely garbled. On the other hand, TCP sorts the data segments so that they can be reassembled in the correct order, while UDP has no such feature at all.

●Format of UDP data segment

Figure 3-5 clearly shows that UDP has significantly less overhead than TCP. Look carefully at the figure and you will notice that UDP does not use windowing in its format nor does it provide acknowledgments in the UDP header.

It is important to understand each field in the UDP segment, as follows:

• Source port number The port number of the application on the sending host.
• Destination Port Number The port number of the requested application on the destination host.
• Length The total length of the UDP header and UDP data.
• Checksum UDP Checksum of the header and the UDP data.
• Data upper layer data.

Like TCP, UDP does not trust the lower layer operations and runs its own CRC. Remember, the CRC result is stored in the FCS (Frame Check Sequence) field, which is why you can see the FCS information.

Note that the overhead is very low! Try looking for the sequence number, acknowledgment number, and window size in the UDP segment. You won't find them because they don't exist!

3. Important concepts about host-to-host layer protocols

After introducing the connection-oriented protocol (TCP) and the connectionless protocol (UDP), it is necessary to summarize them. Table 3-1 lists some important concepts about these two protocols that you should keep in mind.

Let's use the example of making a phone call to help you understand how TCP works. Most people know that before you can talk to someone on the phone, you must first establish a connection to the other party - no matter where the other party is. This is similar to the virtual circuit used by the TCP protocol. If you give the other party important information during a call, you may ask "Did you get it?" or "Did you understand?" This is equivalent to a TCP acknowledgment - it is designed for you to check. When making a phone call (especially on a mobile phone), people often ask "Are you listening?" and say "Goodbye" to end the call. TCP also performs these tasks. In contrast, using UDP is similar to sending a postcard. In this case, you don't need to contact the other party first, but just write down what you want to say and address the postcard, and then mail it. This is similar to UDP's connectionless mode. Since the words on the postcard are not life-threatening, you don't need confirmation from the recipient.

Similarly, UDP does not involve confirmation. Let's look at another diagram, which includes TCP, UDP and their applications, as shown in Figure 3-6.

4. Port Number

TCP and UDP must use port numbers to communicate with upper layers because port numbers keep track of different simultaneous sessions over the network. Source port numbers are dynamically assigned by the source host and are not less than 1024. Port numbers 1023 and lower are defined in RFC 3232 (see www.iana.org), which discusses well-known port numbers.

For virtual circuits that use applications that do not have well-known port numbers, port numbers are randomly assigned based on a specified range. In the TCP data segment, these port numbers identify the source application (process) and the destination application (process). Figure 3-6 illustrates how TCP and UDP use port numbers.

The various port numbers that can be used are explained as follows:

• Port numbers less than 1024 are well-known port numbers, which are defined in RFC 3232;
• The upper layer uses port numbers 1024 and higher to establish sessions with other hosts, and in the data segment, TCP and UDP use them as

as source port and destination port.

In the next few sections, we will look at the analyzer output showing TCP conversations.

●TCP session: source port

Here is a TCP session captured by my analyzer software:

Notice that the source host has chosen a port number, in this case 5973. The destination port number is 23, which is used to inform the receiving host of the purpose of the connection (Telnet). Looking at this session, we can see that the source host has chosen a source port from the range 1024 to 65535, but why would it do this? It is to distinguish between sessions established with different hosts. If the sending host does not use different port numbers, how does the server know where the information is coming from?

The data link layer and network layer protocols use hardware addresses and logical addresses to identify the sending host, respectively, but TCP and upper layer protocols do not do this; they use port numbers.

●TCP session: destination port

When viewing the analyzer output, you may sometimes find that only the source port number is greater than 1024, while the destination port number is a well-known port number, as shown below:

Obviously, the source port number is greater than 1024, but the destination port number is 80 (HTTP service). The server (receiving host) will modify the destination port number if necessary.

In the above output, a syn (synchronous) packet is sent to the target device, which tells the remote target device that it wants to establish a session.

●TCP session: confirmation of synchronization packets

The following output confirms the synchronization packet:

Note that it contains Ack is valid, which indicates that the destination device accepts the source port and agrees to establish a virtual circuit to the source host.

Again, the server's response indicates that the source port number is 80, and the destination port number is 1144, which was sent by the source host. Table 3-2 lists the commonly used applications of the TCP/IP protocol suite, their well-known port numbers, and the transport layer protocols they use. It is important to study and memorize this table.

Note that DNS can use both TCP and UDP, depending on what you want to do. It's not the only application that uses either protocol, but it's something you have to keep in mind.