The last concept to discuss in this chapter is how two hosts (Host A and Host B) can establish end-to-end communication. The end-to-end-to-end-to-end communication service is provided by the transport layer or Layer 4 protocols. These protocols are the focus of this section.
Several protocols work at the transport layer and offer different functionalities. In this section, we focus on two of the most used protocols: User Datagram Protocol (UDP) and Transmission Control Protocol (TCP).
Before we get into the protocol details, we need to discuss the concept of multiplexing, which is at the base of the functionality of UDP and TCP. On a single host, there may be multiple applications that want to use the transport layer protocols (that is, TCP and UDP) to communicate with remote hosts. In Figure 1-79, for example, Host B supports a web server and an FTP server. Let’s imagine that Host A would like to browse and use the FTP services from Host B. It will send two TCP requests to Host B.
The question is, how does Host B differentiate between the two requests and forward the packets to the correct application?
Figure 1-79 Example of TCP Multiplexing
The solution to this problem is provided by multiplexing, which relies on the concept of a socket. A socket is a combination of three pieces of information:
The host IP address A port number
The transport layer protocol
The first two items are sometimes grouped together under the notion of a socket address. A socket (in the case of this example, a TCP socket) is formed by the IP address of the host and a port number, which is used by the host to identify the connection. The pair of sockets on the two hosts, Host A and Host B, uniquely identify a transport layer connection.
For example, the Host A socket for the FTP connection would be (10.0.1.1, 1026), where 10.0.1.1 is the IP address of Host A and 1026 is the TCP port used for the communication. The Host B socket for the same connection would be (10.0.2.2, 21), where 21 is the standard port assigned to FTP services.
Similarly, the Host A socket for the HTTP connection (web service) would be (10.0.1.1, 1027), whereas the Host B socket would be (10.0.2.2, 80), where 80 is the standard port assigned to HTTP services.
The preceding example illustrates the concepts of multiplexing and sockets as applied to a TCP
connection, but the same holds for UDP. For example, when a DNS query is made to a DNS server, as detailed earlier in the section “Domain Name System (DNS)” of this chapter, a UDP socket is used on the DNS resolver and on the DNS server.
An additional concept that’s generally used to describe protocols at the transport layer is whether a formal connection needs to be established before a device can send data. Therefore, the protocols can be classified as follows:
Connection oriented: In this case, the protocol requires that a formal connection be established before data can be sent. TCP is a connection-oriented protocol and provides connection
establishment by using three packets prior to sending data. Generally, connection-oriented protocols have a mechanism to terminate a connection. Connection-oriented protocols are more reliable because the connection establishment allows the exchange of settings and ensures the receiving party is able to receive packets. The drawback is that it adds additional overhead and delay to the transmission of information.
Connectionless: In this case, the protocol allows packets to be sent without any need for a connection. UDP is an example of a connectionless protocol.
We will now examine how TCP and UDP work in a bit more detail.
Transmission Control Protocol (TCP)
The Transmission Control Protocol (TCP) is a reliable, connection-oriented protocol for
communicating over the Internet. Connection oriented means that TCP requires a connection between two hosts to be established through a specific packet exchange before any data packets can be sent.
This is the opposite of connectionless protocols (such as UDP), which don’t require any exchange prior to data transmission.
As mentioned in RFC 793, which specifies the TCP protocol, TCP assumes it can obtain simple and potentially unreliable datagrams (IP packets) from lower-level protocols. TCP provides most of the services expected by a transport layer protocol. This section explains the following services and features provided by TCP:
Multiplexing
Connection establishment and termination Reliability (error detection and recovery) Flow control
You may wonder why we don’t use TCP for all applications due to these important features. The reason is that the reliability offered by TCP is done at the cost of lower speed and the need for
increased bandwidth, in order to manage this process. For this reason, some applications that require fast speed but don’t necessarily need to have all the data packets received to provide the requested level of quality (such as voice/video over IP) rely on UDP instead of TCP.
Table 1-23 summarizes the services provided by TCP.
Table 1-23 TCP Services TCP Header
Application data is encapsulated in TCP segments by adding a TCP header to the application data.
These segments are then passed to IP for further encapsulation, thus ensuring that the packets can be routed on the network, as shown on Figure 1-80.
Figure 1-80 Application Data Encapsulated in TCP Segments
The TCP header is more extensive compared to the UDP header; this is because it needs additional fields to provide additional services and features. Figure 1-81 shows the TCP header structure.
Figure 1-81 TCP Header Structure The main TCP header fields are as follows:
Source and Destination Port: These are used to include the source and destination port for a given TCP packet. They are probably the most important fields within the TCP header and are used to correctly identify a TCP connection and TCP socket.
Sequence Number (32 bits): When the SYN flag bit is set to 1, this is the initial sequence number (ISN) and the first data byte is ISN+1. When the SYN flag bit is set to 0, this is the sequence number of the first data byte in this segment.
Acknowledgment Number (32 bits): Once the connection is established, the ACK flag bit is set to 1, and the acknowledgment number provides the sequence number of the next data payload the sender of the packet is expecting to receive.
Control Flags (9 bits, 1 bit per flag): This field is used for congestion notification and to carry TCP flags.
ECN (Explicit Congestion Notification) Flags (3 bits): The first three flags (NS, CWR, ECE) are related to the congestion notification feature that has been recently defined in RFC 3168 and RFC 3540 (following RFC 793 about the TCP protocol in general). This feature supports end-to-end network congestion notification, in order to avoid dropping packets as a sign of network congestion.
TCP flags include the following:
URG: The Urgent flag signifies that Urgent Pointer data should be reviewed.
ACK: The Acknowledgment bit flag should be set to 1 after the connection has been established.
PSH: The Push flag signifies that the data should be pushed directly to an application.
RST: The Reset flag resets the connection.
SYN: The Synchronize (sequence numbers) flag is relevant for connection establishment, and should only be set within the first packets from both of the hosts.
FIN: This flag signifies that there is no more data from sender.
Window (16 bits): This field indicates the number of data bytes the sender of the segment is able to receive. This field enables flow control.
Urgent pointer (16 bits): When the URG flag is set to 1, this field indicates the sequence number of the data payload following the urgent data segment. The TCP protocol doesn’t define what the user will do with the urgent data; it only provides notification on urgent data pending processing.
TCP Connection Establishment and Termination
As mentioned at the beginning of this section, the fact that the TCP protocol is connection oriented means that before any data is exchanged, the two hosts need to go through a process of establishing a connection. This process is often referred to as “three-way-handshake” because it involves three packets and the main goal is to synchronize the sequence numbers so that the hosts can exchange data, as illustrated in Figure 1-82.
Figure 1-82 TCP Three-way Handshake Let’s examine the packet exchange in more detail:
First packet (SYN): The client starts the process of establishing a connection with a server by sending a TCP segment that has the SYN bit set to 1, in order to signal to the peer that it wants to synchronize the sequence numbers and establish the connection. The client also sends its initial sequence number (here X), which is a random number chosen by a client.
Second packet (SYN-ACK): The server responds with a SYN-ACK packet where it sends its own request for synchronization and its initial sequence number (another random number; here Y). Within the same packet, the server also sends the acknowledgment number X+1,
acknowledging the receipt of a packet with the sequence number X and requesting the next packet with the sequence number X+1.
Third packet (ACK): The client responds with a final acknowledgment, requesting the next packet with the sequence number Y+1.
In order to terminate a connection, peers go through a similar packet exchange, as shown in Figure 1-83.
Figure 1-83 TCP Connection Termination
The process starts with the client’s application notifying the TCP layer on the client side that it wants to terminate the connection. The client sends a packet with the FIN bit set, to which the server
responds with an acknowledgment, acknowledging the receipt of the packet. At that point, the server notifies the application on its side that the other peer wishes to terminate the connection. During this time, the client will still be able to receive traffic from the server, but will not be sending any traffic to the server. Once the application on the server side is ready to close down the connection, it signals to the TCP layer that the connection is ready to be closed, and the server sends a FIN packet as well, to which the client responds with an acknowledgment. At that point, the connection is terminated.
TCP Socket
The concept of multiplexing has already been introduced as a way to enable multiple applications to run on the same host and sockets by uniquely identifying a connection with an IP address, transport protocol, and port number.
There are some “well-known” applications that use designated port numbers (for example, WWW uses TCP port 80). This means that the web server will keep its socket for TCP port 80 open, listening to requests from various hosts. When a host tries to open a connection to a web server, it will use TCP port 80 as a destination port, and it will choose a random port number (greater than 1024) as a source port. Random port numbers need to be greater than 1024 because the ones up to 1024 are reserved for well-known applications.
Table 1-24 shows a list of some of the most used applications and their port numbers. A full list of ports used by known services can be found at http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml.
Table 1-24 Commonly Used TCP Applications and Associated Port Numbers
FTP (File Transfer Protocol) usesTCP port 20 for transferring the data and a separate connection on port 21 for exchanging control information (for example, FTP commands). Depending on whether the FTP server is in active or passive mode, different port numbers can be involved.
SSH (Secure Shell) is a protocol used for remote device management by allowing a secure
(encrypted) connection over an unsecure medium. Telnet can also be used for device management;
however, this is not recommended because FTP is not secure—data is sent in plaintext.
SMTP (Simple Mail Transfer Protocol) is used for email exchange. Typically, the client would use this protocol for sending emails, but would use POP3 or IMAP to retrieve emails from the mail server.
DNS (Domain Name System) uses UDP port 53 for domain name queries from hosts that allow other hosts to find out about the IP address for a specific domain name, but it uses TCP port 53 for
communication between DNS servers for completing DNS zone transfers.
HTTP (Hypertext Transfer Protocol) is an application-based protocol that is used for accessing content on the Web. HTTPS (HTTP over Secure Socket Layer) is basically HTTP that uses TLS (Transport Layer Security) and SSL (Secure Sockets Layer) for encryption. HTTP is widely used on the Internet for secure communication because it allows encryption and server authentication.
BGP (Border Gateway Protocol) is an exterior gateway protocol used for exchanging routing information between different autonomous systems. It’s the routing protocol of the Internet.
TCP Error Detection and Recovery
TCP provides reliable delivery because the protocol is able to detect errors in transmission (for example, lost, damaged, or duplicated segments) and recover from such errors. This is done through the use of sequence numbers, acknowledgments, and checksum fields in the TCP header.
Each segment transmitted is marked with a sequence number, allowing the receiver of the segments to order them and provide acknowledgment on which segments have been received. If the sender doesn’t get acknowledgment, it will send the data again.
Figure 1-84 shows an example of sequence numbers and acknowledgments in a typical scenario.
Figure 1-84 Example of TCP Acknowledgement and Sequence Numbers
In this example, the client is sending three segments, each with 100 bytes of data. If the server has received all three segments in order, it would send a packet with the acknowledgment set to 400, which literally means “I’ve received all the segments with sequence numbers up to 399, and I am now expecting a segment with the sequence number 400.”
The fact that the segments have sequence numbers will allow the server to properly align the data upon receipt—for example, if for any reason it receives the segments in a different order or if it receives any duplicates.
Figure 1-85 shows how TCP detects and recovers from an error.
Figure 1-85 TCP Error Detection and Recovery
Imagine now that the client sends three packets with sequence numbers 100, 200, and 300. Due to some error in the transmission, the packet with the sequence number 200 gets lost or damaged. If the segment gets damaged during transmission, the TCP protocol would be able to detect this through the checksum number available within the TCP header. Because the packet with the sequence number 200 has not been received properly, the server will only send acknowledgement up to 200. This indicates to the client that it needs to resend that packet. When the server receives the missing packet, it will resume the normal acknowledge to 400, because it already received the packet with sequence numbers 300 and 400. This indicates to the client that it can send packets with sequence 500 and so on. It is worth mentioning that if the receiver doesn’t receive the packet with the sequence number 200, it will continue to send packets with acknowledgment number 200, asking for the missing packet.
TCP Flow Control
The TCP protocol ensures flow control through the use of “sliding windows,” by which a receiving host “tells” the sender how many bytes of data it can handle at a given time before waiting for an acknowledgment—this is called the window size. This mechanism works for both the client and server. For example, the client can ask the server to slow down, and the server can use this
mechanism to ask the client to slow down or even to increase the speed. This allows the TCP peers to increase or reduce the speed of transmission depending on the conditions on the network and
processing capability, and to avoid the situation of having a receiving host overwhelmed with data.
The size of the receiving window is communicated through the “Window” field within the TCP header. Figure 1-86 shows how the window size gets adjusted based on the capability of the receiving host.
Figure 1-86 Example of TCP Flow Control
Initially, the server notifies the client that it can handle a window size of 300 bytes, so the client is able to send three segments of 100 bytes each, before getting the acknowledgment. However, if for some reason the server becomes overwhelmed with data that needs to be processed, it will notify the client that it can now handle a smaller window size.
The receiving host (for example, the server) has a certain buffer that it fills in with data received during a TCP connection, which could determine the size of this window. In ideal conditions, the receiving host may be able to process all the received data instantaneously, and free up the buffer again, leaving the window at the same size. However, if for some reason it is not able to process the data at that speed, it will reduce the window, which will notify the client of the problem. In Figure 1-86, the receiving party (the server) notifies the client that it needs to use a smaller window size of 200 bytes instead of the initial 300-byte window. The client adjusts its data stream accordingly. This process is dynamic, meaning that the server could also increase the window size.
The Window field in TCP header is 16 bits long, which means that the maximum window size is 65,535 bytes. In order to use higher window sizes, a scaling factor within the TCP Options field can be used. This TCP option will get negotiated within the initial three-way handshake.
User Datagram Protocol (UDP)
Like TCP, the User Datagram Protocol (UDP) is one of the most used transport layer protocols.
Unlike TCP, however, UDP is designed to reduce the number of protocol iterations and complexity. It in fact does not establish any connection channel and in essence just wraps higher-layer information in a UDP segment and passes it to IP for transmission. UDP is usually referred as a “connectionless”
protocol.
Due to its simplicity, UDP does not implement any mechanism for error control and retransmission; it leaves that task to the higher-layer protocols if required. Generally, UDP is used in applications where the low latency and low jitter are more important than reliability. A well-known use case for UDP is Voice over IP. UDP is described in RFC 768.
UDP Header
The UDP header structure is shorter and less complex than TCP’s. Figure 1-87 shows an example of a UDP header.
Figure 1-87 UDP Header The UDP header includes the following fields:
Source and Destination Port: Similar to the TCP header, these fields are used to determine the socket address and to correctly send the information to the higher-level application.
Length: Includes the length of the UDP segment.
Checksum: It is built based on a pseudo header which includes information from the IP header (source and destination addresses) and information from the UDP header. Refer to the RFC for more information on how the checksum is calculated.
UDP Socket and Known UDP Application
As described earlier, UDP uses the same principle of multiplexing and sockets that’s used by TCP.
The protocol information on the socket determines whether it is a TCP or UDP type of socket. As with TCP, UDP has well-known applications that use standard port numbers while listening for arriving packets. Table 1-25 provides an overview of known applications and their standard ports.
Table 1-25 Commonly Used UDP Applications and Associated Port Numbers
This concludes the overview of networking fundamentals. The next chapter introduces the concepts of
This concludes the overview of networking fundamentals. The next chapter introduces the concepts of