The main purpose of the Host-to-Host layer protocols 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:
- Transmission Control Protocol (TCP)
- User Datagram Protocol (UDP)
If you want to know more about Process/Application Layer, then you can click the link.
In addition, we’ll look at some of the key host-to-host protocol concepts, as well as the port numbers.
Transmission Control Protocol (TCP)
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 stacks 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 stack contacts the destination’s TCP stack 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 full-duplex, connection-oriented, reliable, and accurate protocol, but 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. And since today’s networks are much more reliable than those of yore, this added reliability is often unnecessary.
TCP segment format
Since the upper layers just send a data stream to the protocols in the Transport layers, I’ll demonstrate how TCP segments a data stream and prepares it for the Internet Layer.
When the Internet Layer receives the data stream, it routes the segments as packets through an internetwork. The segments are handed to the receiving host’s Host-to-Host layer protocol, which rebuilds the data stream to hand to the upper layer applications or protocols.
The following figure shows the TCP segment format. It also shows the different fields within the TCP header.
The TCP header is 20 bytes long, or up to 24 bytes with options. You need to understand what each field in the TCP segment is:
Source port: The port number of the application on the host sending the data.
Destination port: The port number of the application requested on the destination host.
Sequence Number: A number used by TCP that puts the data back in the correct order or retransmits missing or damaged data, a process called sequencing.
Acknowledgment Number: The TCP octet that is expected next.
Header Length: The number of 32-bit words in the TCP header. This indicates where the data begins. The TCP header (even one including options) is an integral number of 32 bits in length.
Reserved: Always set to zero.
Code Bits: Control functions used to set up and terminate a session.
Window: The window size the sender is willing to accept, in octets.
Checksum: The cyclic redundancy check (CRC), because TCP doesn’t trust the lower layers and checks everything. The CRC checks the header and data fields.
Urgent: A valid field only if the urgent pointer in the code bits are set. If so, this value indicates the offset from the current sequence number, in octets, where the first segment of non-urgent data begins.
Options: Maybe 0 or a multiple of 32 bits if any. What this means is that no options have to be present (option size of 0). However, if any options are used that do not cause the option field to total a multiple of 32 bits, padding of 0s must be used to make sure the data begins on a 32-bit boundary.
Data: Handed down to the TCP protocol at the Transport layer, which includes the upper layer headers.
Let’s take a look at a TCP segment copied from a network analyzer:
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 19 35 11 2b 19 35 +. 11 2b 19
Frame Check Sequence 0x0d00000fDid you notice that everything I talked about earlier is in the segment? As you can see from the number of fields in the header, TCP creates a lot of overhead. Application developers may opt for efficiency over reliability to save overhead, so User Datagram Protocol was also defined at the Transport layer as an alternative.
User Datagram Protocol (UDP)
If you were to compare User Datagram Protocol (UDP) the TCP, the former is basically the scaled-down economy model that’s sometimes referred to as a thin protocol. As 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 doesn’t offer all the bells and whistles of TCP either, 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. (UDP is covered thoroughly in Request for Comments 768.)
There are some situations in which it would definitely be wise for developers to opt for UDP rather than TCP. Remember the watchdog SNMP up there at the Process/Application Layer? 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 reliability is already handled at the Process/Application layer. Network File System (NFS) handles its own reliability issues, making the use of TCP both impractical and redundant. But ultimately, it’s up to the application developer to decide whether to use UDP or TCP, not the user who wants to transfer data faster.
UDP doesn’t sequence the segments and doesn’t care in which order the segments arrive at the destination. 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 doesn’t 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. Because of this, it’s 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 developer a choice when running the Internet Protocol stack: TCP for reliability or UDP for faster transfers.
So if you are using voice over IP (VoIP), for example, you really don’t want to use UDP, because if the segments arrive out of order (very common in IP networks), they will just be passed up to the next OSI (DoD) layer in whatever order they’re received, resulting in some seriously garbled data. On the other hand, TCP sequences the segments so they get put back together in exactly the right order something UDP just can’t do.
UDP segment format
The following figure clearly illustrates UDP’s markedly low overhead as compared to TCP’s hungry usage. Look at the figure carefully. Can you see that UDP doesn’t use windowing or provide for acknowledgments in the UDP header?
It’s important for you to understand what each field in the UDP segment is:
Source Port: Port number of the application on the host sending the data.
Destination port: Port number of application requests on the destination host.
Length: Length of UDP header and UDP data.
Checksum: Checksum of both the UDP header and UDP data fields.
Data: Upper layer data.
UDP, like TCP, doesn’t trust the lower layers and runs its own CRC. Remember that the Frame Check Sequence (FCS) is the field that houses the CRC, which is why you can see the FCS information.
The following shows a UDP segment caught on a network analyzer.
UDP User Datagram Protocol
Source Port 1085
Destination port 5136
Length 41
Checksum 0x7a3c
UDP data area …Z……00 01 5a 96 00 01 00 00 00 00 00 11 0000 00 ……C…2._C._C 2e 03 00 43 02 1e 32 0a 00 0a 00 80 43 00 80
Frame Check Sequence 0x00000000 Notice that low overhead! Try to find the sequence number, ack number, and window size in the UDP segment. You can’t because they just aren’t there.