Chapter 5. Transport Layer

What is the purpose of the transport layer in managing the transportation of data in end-to-end communication?

What are the characteristics of the TCP and UDP protocols, including port numbers and their uses?

How do the TCP session establishment and termination processes facilitate reliable communication?

How are TCP protocol data units (PDUs) transmitted and acknowledged to guarantee delivery?

What is the UDP client process to establish communication with a server?

How can you determine whether high-reliability TCP transmissions or non-guaranteed UDP transmissions are best suited for common applications?

port number page 172

User Datagram Protocol (UDP) page 174

segments page 175

connection-oriented protocol page 178

flow control page 179

stateful protocol page 179

datagrams page 181

stateless protocol page 181

socket page 184

socket pair page 184

overhead page 189

three-way handshake page 190

initial sequence number (ISN) page 191

SYN segment page 192

acknowledgement (ACK) flag page 192

SYN flag page 192

Finish (FIN) control flag page 194

SEQ number page 196

ACK number page 196

expectational acknowledgement page 196

window size page 197

dynamic window sizes page 200

connectionless page 201

Data from each of these applications is packaged, transported, and delivered to the appropriate server daemon or application on the destination device. The processes described in the Open Systems Interconnection (OSI) transport layer accept data from the application layer and prepare it for addressing at the network layer. The transport layer is responsible for the overall end-to-end transfer of application data.

In this chapter we will examine the role of the transport layer in encapsulating application data for use by the network layer. The transport layer also encompasses these functions:

Enables multiple applications to communicate over the network at the same time on a single device

Ensures that, if required, all the data is received reliably and in order by the correct application

Employs error handling mechanisms

The transport layer accepts data from different applications and passes that data down to the lower layers as manageable pieces that can be multiplexed, or inserted with other data packets, over the media. The transport layer provides for the segmentation of data and the controls necessary to reassemble these segments into the various communication streams. In TCP/IP, these segmentation and reassembly processes can be achieved using two very different transport layer protocols: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).

The primary responsibilities of transport layer protocols are

Tracking the individual communication between applications on the source and destination hosts

Segmenting data for manageability and reassembling segmented data into streams of application data at the destination

Identifying the proper application for each communication stream

At the destination, the transport layer must be able to reconstruct the pieces of data into a complete data stream that is useful to the application layer. The protocols at the transport layer describe how the transport layer header information is used to reassemble the data pieces into streams to be passed to the application layer.

Figure 5-5 shows that segmenting the data into smaller chunks enables many different communications, from many different users, to be interleaved (multiplexed) on the same network. Segmentation of the data by transport layer protocols also provides the means to both send and receive data when running multiple applications concurrently on a computer.

Without segmentation, only one application would be able to receive data. For example, with a streaming video, the media would be completely consumed by the one communication stream instead of shared. You could not receive emails, chat on instant messenger, or view web pages while also viewing the video.

To identify each segment of data, the transport layer adds to the segment a header containing binary data. This header contains fields of bits. It is the values in these fields that enable different transport layer protocols to perform different functions in managing data communication.

IP is concerned only with the structure, addressing, and routing of packets. IP does not specify how the delivery or transportation of the packets takes place. Transport protocols specify how to transfer messages between hosts. TCP/IP provides two transport layer protocols, Transmission Control Protocol (TCP) and User Datagram Protocol (UDP), as shown in Figure 5-6. IP uses these transport protocols to enable hosts to communicate and transfer data.

TCP is considered a reliable, full-featured transport layer protocol, which ensures that all of the data arrives at the destination. In contrast, UDP is a very simple transport layer protocol that does not provide for any reliability.

With TCP, the three basic operations of reliability are

Tracking transmitted data segments

Acknowledging received data

Retransmitting any unacknowledged data

TCP breaks up a message into small pieces known as segments. The segments are numbered in sequence and passed to the IP process for assembly into packets. TCP keeps track of the number of segments that have been sent to a specific host from a specific application. If the sender does not receive an acknowledgement within a certain period of time, it assumes that the segments were lost and retransmits them. Only the portion of the message that is lost is re-sent, not the entire message. On the receiving host, TCP is responsible for reassembling the message segments and passing them to the application. FTP and HTTP are examples of applications that use TCP to ensure data delivery.

These reliability processes place additional overhead on network resources due to the processes of acknowledgement, tracking, and retransmission. To support these reliability processes, more control data is exchanged between the sending and receiving hosts. This control information is contained in a TCP header.

UDP provides just the basic functions for delivering data segments between the appropriate applications, with very little overhead and data checking. UDP is known as a best-effort delivery protocol. In the context of networking, best-effort delivery is referred to as unreliable because there is no acknowledgement that the data is received at the destination. With UDP, there are no transport layer processes that inform the sender if successful delivery has occurred.

UDP is similar to placing a regular, non-registered letter in the mail. The sender of the letter is not aware of whether a receiver is available to receive the letter, nor is the post office responsible for tracking the letter or informing the sender if the letter does not arrive at the final destination.

For some applications, segments must arrive in a very specific sequence to be processed successfully. With other applications, all data must be fully received before any of it is considered useful. In both of these instances, TCP is used as the transport protocol. For example, applications such as databases, web browsers, and email clients require that all data that is sent arrives at the destination in its original condition. Any missing data could cause a corrupt communication that is either incomplete or unreadable. Therefore, these applications are designed to use TCP. The additional network overhead is considered to be required for these applications.

In other cases, an application can tolerate some data loss during transmission over the network, but delays in transmission are unacceptable. UDP is the better choice for these applications because less network overhead is required. UDP is preferable with applications such as streaming audio, video, and Voice over IP (VoIP). Acknowledgements would slow down delivery, and retransmissions are undesirable.

For example, if one or two segments of a video stream fail to arrive, it creates a momentary disruption in the stream. This may appear as distortion in the image, but may not even be noticeable to the user. On the other hand, the image in a streaming video would be greatly degraded if the destination device had to account for lost data and delay the stream while waiting for retransmissions. In this case, it is better to render the best video possible with the segments received, and forego reliability.

Internet radio is another example of an application that uses UDP. If some of the message is lost during its journey over the network, it is not retransmitted. If a few packets are missed, the listener might hear a slight break in the sound. If TCP were used and the lost packets were re-sent, the transmission would pause to receive them and the disruption would be more noticeable.

Figure 5-7 depicts key differences between the TCP and UDP protocols in the transport layer.

Connection-oriented conversations by establishing sessions

Reliable delivery

Ordered data reconstruction

Flow control

TCP incurs additional overhead to gain these functions. As shown in Figure 5-8, each TCP segment has 20 bytes of overhead in the header encapsulating the application layer data. This is considerably more than a UDP segment, which only has 8 bytes of overhead. Extra overhead in TCP includes

Sequence number (32 bits): Used for data reassembly purposes.

Acknowledgement number (32 bits): Indicates the data that has been received.

Header length (4 bits): Known as “data offset.” Indicates the length of the TCP segment header.

Reserved (6 bits): This field is reserved for the future.

Control bits (6 bits): Includes bit codes, or flags, that indicate the purpose and function of the TCP segment.

Window size (16 bits): Indicates the number of segments that can be accepted at one time.

Checksum (16 bits): Used for error checking of the segment header and data.

Urgent (16 bits): Indicates if data is urgent.

Examples of applications that use TCP are web browsers, email, and file transfers.

The following features describe UDP:

Connectionless: UDP does not establish a connection between the hosts before data can be sent and received.

Unreliable delivery: UDP does not provide services to ensure that the data will be delivered reliably. There are no processes within UDP to have the sender retransmit any data that is lost or is corrupted.

No ordered data reconstruction: Occasionally data is received in a different order than it was sent. UDP does not provide any mechanism for reassembling the data in its original sequence. The data is simply delivered to the application in the order that it arrives.

No flow control: There are no mechanisms within UDP to control the amount of data transmitted by the source to avoid overwhelming the destination device. The source sends the data. If resources on the destination host become overtaxed, the destination host mostly likely drops data sent until resources become available. Unlike TCP, with UDP there is no mechanism for automatic retransmission of dropped data.

Figure 5-9 depicts the UDP datagram. Because it has less overhead than the TCP datagram, it is only 8 bytes in length.

One of the most important requirements for delivering live video and voice over the network is that the data continues to flow quickly. Video and voice applications can tolerate some data loss with minimal or no noticeable effect, and are perfectly suited to UDP.

UDP is a stateless protocol, meaning neither the client nor the server is obligated to keep track of the state of the communication session. UDP is not concerned with reliability or flow control. Data may be lost or received out of sequence without any UDP mechanisms to recover or reorder the data. If reliability is required when using UDP as the transport protocol, it must be handled by the application.

For reliability, users require that an email or web page be completely received and presented in full, for the information to be considered useful. Slight delays in loading the email or web page are generally acceptable as long as the final product is shown in its entirety and correctly. In this example, the network manages the resending or replacement of missing information, and does not display the final product until everything is received and correctly assembled.

In contrast, occasionally missing small parts of a telephone conversation might be considered acceptable. Even if some small parts of a few words are dropped, one can either infer the missing audio from the context of the conversation or ask the other person to repeat what was said. This is considered preferable to the incurred delays if the network were to manage and resend missing segments. In this example, the user, not the network, manages the resending or replacement of missing information.

As shown in Figure 5-10, for TCP and UDP to manage these simultaneous conversations with varying requirements, the TCP- and UDP-based services must keep track of the various applications that are communicating. To differentiate the segments and datagrams for each application, both TCP and UDP have header fields that can uniquely identify these applications. These unique identifiers are the port numbers.

When a message is delivered using either TCP or UDP, the protocols and services requested are identified by a port number. A port is a numeric identifier within each segment that is used to keep track of specific conversations and destination services requested. Every message that a host sends contains both a source port and a destination port.

Destination port: The client places a destination port number in the segment to tell the destination server which service is being requested. For example, port 80 refers to HTTP or web service. When a client specifies port 80 in the destination port, the server that receives the message knows that web services are being requested. A server can offer more than one service simultaneously. For example, a server can offer web services on port 80 at the same time that it offers FTP connection establishment on port 21.

Source port: The source port number is randomly generated by the sending device to identify a conversation between two devices. This allows multiple conversations to occur simultaneously. In other words, a device can send multiple HTTP service requests to a web server at the same time. The separate conversations are tracked based on the source ports.

The source and destination ports are placed within the segment. The segments are then encapsulated within an IP packet. The IP packet contains the IP address of the source and destination. The combination of the source and destination IP addresses and the source and destination port numbers is known as a socket. The socket is used to identify the server and service being requested by the client. Every day thousands of hosts communicate with millions of different servers. Those communications are identified by the sockets.

It is the combination of the transport layer port number and the network layer IP address of the host that uniquely identifies a particular application process running on an individual host device. This combination is called a socket. A socket pair, consisting of the source and destination IP addresses and port numbers, is also unique and identifies the specific conversation between the two hosts.

A client socket might look like what is shown in Figure 5-11, with 1099 representing the source port number: 192.168.1.5:1099.

The socket on a web server might be 192.168.1.7:80.

Together, these two sockets combine to form a socket pair: 192.168.1.5:1099, 192.168.1.7:80.

With the creation of sockets, communication endpoints are known so that data can move from an application on one host to an application on another. Sockets enable multiple processes running on a client to distinguish themselves from each other, and multiple connections to a server process to be distinguished from each other.

The source port of a client request is randomly generated. This port number acts like a return address for the requesting application. The transport layer keeps track of this port and the application that initiated the request so that when a response is returned, it can be forwarded to the correct application. The requesting application port number is used as the destination port number in the response coming back from the server.

The Internet Assigned Numbers Authority (IANA) assigns port numbers. IANA is a standards body that is responsible for assigning various addressing standards.

There are different types of port numbers:

Well-known ports (numbers 0 to 1023): As shown in Table 5-1, numbers are reserved for services and applications. They are commonly used for applications such as HTTP (web server), IMAP/SMTP (email server), and Telnet. By defining these well-known ports for server applications, client applications can be programmed to request a connection to that specific port, and its associated service.

Registered ports (numbers 1024 to 49151): As shown in Table 5-2, these port numbers are assigned to user processes or applications. These processes are primarily individual applications that a user has chosen to install, rather than common applications that would receive a well-known port number. When not used for a server resource, these ports may also be dynamically selected by a client as its source port.

Dynamic or private ports (numbers 49152 to 65535): Also known as ephemeral ports, these are usually assigned dynamically to client applications when the client initiates a connection to a service. The dynamic port is most often used to identify the client application during communication, whereas the client uses the well-known port to identify and connect to the service being requested on the server. It is uncommon for a client to connect to a service using a dynamic or private port (although some peer-to-peer file sharing programs do use these ports).

A current list of port numbers and the associated applications can be found at http://www.iana.org/assignments/port-numbers.

Sometimes it is necessary to know which active TCP connections are open and running on a networked host. Netstat is an important network utility that can be used to verify those connections. Netstat lists the protocol in use, the local address and port number, the foreign address and port number, and the connection state.

Unexplained TCP connections can pose a major security threat because they can indicate that something or someone is connected to the local host. Additionally, unnecessary TCP connections can consume valuable system resources, thus slowing down the host’s performance. Netstat should be used to examine the open connections on a host when performance appears to be compromised.

Many useful options are available for the netstat command. Example 5-1 shows output information from the netstat command.

Some applications transmit large amounts of data—in some cases, many gigabytes. It would be impractical to send all of this data in one large piece. No other network traffic could be transmitted while this data was being sent. A large piece of data could take minutes or even hours to send. In addition, if there were any errors, the entire data file would be lost or have to be re-sent. Network devices would not have memory buffers large enough to store this much data while it is transmitted or received. The limit varies depending on the networking technology and specific physical medium in use.

Dividing application data into segments ensures both that data is transmitted within the limits of the media and that data from different applications can be multiplexed on to the media.

Although services using UDP also track the conversations between applications, they are concerned neither with the order in which the information was transmitted nor with maintaining a connection. There is no sequence number in the UDP header. UDP is a simpler design and generates less overhead than TCP, resulting in a faster transfer of data.

Information may arrive in a different order than it was transmitted because different packets may take different paths through the network. An application that uses UDP must tolerate the fact that data may not arrive in the order in which it was sent.

After a session has been established, and data transfer begins, the destination sends acknowledgements to the source for the segments that it receives. These acknowledgements form the basis of reliability within the TCP session. When the source receives an acknowledgement, it knows that the data has been successfully delivered and that it can quit tracking that data. If the source does not receive an acknowledgement within a predetermined amount of time, it retransmits that data to the destination.

Part of the additional overhead of using TCP is the network traffic generated by acknowledgements and retransmissions. The establishment of sessions creates overhead in the form of additional segments being exchanged. There is also additional overhead on the individual hosts, created by the necessity to keep track of which segments are awaiting acknowledgement and by the retransmission process.

Each application process running on the server is configured to use a port number, either by default or manually by a system administrator. An individual server cannot have two services assigned to the same port number within the same transport layer services. A host running a web server application and a file transfer application cannot have both configured to use the same port (for example, TCP port 8080). An active server application assigned to a specific port is considered to be open, which means that the transport layer accepts and processes segments addressed to that port. Any incoming client request addressed to the correct socket is accepted and the data is passed to the server application. There can be many simultaneous ports open on a server, one for each active server application. It is common for a server to provide more than one service at the same time, such as a web server and an FTP server.

One way to improve security on a server is to restrict server access to only those ports associated with the services and applications that should be accessible by authorized requestors.

When two hosts communicate using TCP, a connection is established before data can be exchanged. After the communication is completed, the sessions are closed and the connection is terminated. The connection and session mechanisms enable TCP’s reliability function. See Figure 5-12 for the steps to establish and terminate a TCP connection.

Hosts track each data segment within a session and exchange information about what data is received using the information in the TCP header. TCP is a full-duplex protocol, where each connection represents two one-way communication streams, or sessions. To establish the connection, the hosts perform a three-way handshake. Control bits in the TCP header indicate the progress and status of the connection. The three-way handshake

Establishes that the destination device is present on the network

Verifies that the destination device has an active service and is accepting requests on the destination port number that the initiating client intends to use for the session

Informs the destination device that the source client intends to establish a communication session on that port number

In TCP connections, the host client establishes the connection with the server. The three steps in TCP connection establishment are

Step 1. The initiating client requests a client-to-server communication session with the server.

Step 2. The server acknowledges the client-to-server communication session and requests a server-to-client communication session.

Step 3. The initiating client acknowledges the server-to-client communication session.

The following sections analyze each of these steps in turn.

Within the TCP segment header, there are six 1-bit fields that contain control information used to manage the TCP processes:

URG: Urgent pointer field significant

ACK: Acknowledgement field significant

PSH: Push function

RST: Reset the connection

SYN: Synchronize sequence numbers

FIN: No more data from sender

The ACK and SYN fields are relevant to our analysis of the three-way handshake.

Step 1. The initiating client requests a client-to-server communication session with the server.

A TCP client begins the three-way handshake by sending a segment with the sequence number (SYN) control flag set, indicating an initial value in the sequence number field in the header. This initial value for the sequence number, known as the initial sequence number (ISN), is randomly chosen and is used to begin tracking the flow of data from the client to the server for this session. The ISN in the header of each segment is increased by one for each byte of data sent from the client to the server as the data conversation continues.

As shown in Figure 5-13, output from a protocol analyzer shows the SYN control flag and the relative sequence number. The SYN control flag is set and the relative sequence number is at 0. Although the protocol analyzer in Figure 5-13 indicates the relative values for the sequence and acknowledgement numbers, the true values are 32-bit binary numbers. The figure shows the 4 bytes represented in hexadecimal.

The TCP server must acknowledge the receipt of the SYN segment from the client to establish the session from the client to the server. To do so, the server sends a segment back to the client with the acknowledgement (ACK) flag set indicating that the acknowledgement number is significant. With this flag set in the segment, the client recognizes this as an acknowledgement that the server received the SYN from the TCP client.

The value of the acknowledgement number field is equal to the ISN plus 1. This establishes a session from the client to the server. The ACK flag remains set for the balance of the session. Recall that the conversation between the client and the server is actually two one-way sessions: one from the client to the server, and the other from the server to the client. In this second step of the three-way handshake, the server must initiate the response to the client. To start this session, the server uses the SYN flag in the same way that the client did. It sets the SYN control flag in the header to establish a session from the server to the client. The SYN flag indicates that the initial value of the sequence number field is in the header. This value is used to track the flow of data in this session from the server back to the client.

As shown in Figure 5-14, the protocol analyzer output shows that the ACK and SYN control flags are set and the relative sequence and acknowledgement numbers are displayed.

Finally, the TCP client responds with a segment containing an ACK that is the response to the TCP SYN sent by the server. There is no user data in this segment. The value in the acknowledgement number field contains one more than the ISN received from the server. After both sessions are established between client and server, all additional segments exchanged in this communication will have the ACK flag set.

As shown in Figure 5-15, the protocol analyzer output shows the ACK control flag set and the relative sequence and acknowledgement numbers.

Security can be added to the data network by

Denying the establishment of TCP sessions

Only allowing sessions to be established for specific services

Only allowing traffic as a part of already established sessions

These security measures can be implemented for all TCP sessions or only for selected sessions.

Step 1. When the client has no more data to send in the stream, it sends a segment with the FIN flag set.

Step 2. The server sends an ACK to acknowledge the receipt of the FIN to terminate the session from client to server.

Step 3. The server sends a FIN to the client, to terminate the server-to-client session.

Step 4. The client responds with an ACK to acknowledge the FIN from the server.

When the client has no more data to transfer, it sets the FIN flag in the header of a segment. Next, the server end of the connection sends a normal segment containing data with the ACK flag set using the acknowledgement number, confirming that all the bytes of data have been received. When all segments have been acknowledged, the session is closed.

The session in the other direction is closed using the same process. The receiver indicates that there is no more data to send by setting the FIN flag in the header of a segment sent to the source. A return acknowledgement confirms that all bytes of data have been received, and that session is, in turn, closed.

It is also possible to terminate the connection by a three-way handshake. When the client has no more data to send, it sends a FIN to the server. If the server also has no more data to send, it can reply with both the FIN and ACK flags set, combining two steps into one. The client then replies with an ACK.

During session setup, an initial sequence number (ISN) is set. This ISN represents the starting value for the bytes for this session that is transmitted to the receiving application. As data is transmitted during the session, the sequence number is incremented by the number of bytes that have been transmitted. This data byte tracking enables each segment to be uniquely identified and acknowledged. Missing segments can be identified.

Segment sequence numbers enable the reliability by indicating how to reassemble and reorder received segments.

The receiving TCP process places the data from a segment into a receiving buffer. Segments are placed in the proper sequence number order and passed to the application layer when reassembled. Any segments that arrive with non-contiguous sequence numbers are held for later processing. Then, when the segments with the missing bytes arrive, these segments are processed in order.

The sequence (SEQ) number and acknowledgement (ACK) number are used together to confirm receipt of the bytes of data contained in the transmitted segments. The SEQ number indicates the relative number of bytes that have been transmitted in this session, including the bytes in the current segment. TCP uses the ACK number sent back to the source to indicate the next byte that the receiver expects to receive. This is called expectational acknowledgement.

The source is informed that the destination has received all bytes in this data stream up to, but not including, the byte indicated by the ACK number. The sending host is expected to send a segment that uses a sequence number that is equal to the ACK number.

Remember, each connection is actually two one-way sessions. SEQ and ACK numbers are being exchanged in both directions.

In the example in Figure 5-16, the host on the left is sending data to the host on the right. It sends a segment containing 10 bytes of data for this session and a sequence number equal to 1 in the header.

The receiving host receives the segment at Layer 4 and determines that the sequence number is 1 and that it has 10 bytes of data. The host then sends a segment back to the host on the left to acknowledge the receipt of this data. In this segment, the host sets the ACK number to 11 to indicate that the next byte of data it expects to receive in this session is byte number 11. When the sending host receives this acknowledgement, it can now send the next segment containing data for this session starting with byte number 11.

Looking at this example, if the sending host had to wait for acknowledgement of receiving each 10 bytes, the network would have a lot of overhead. To reduce the overhead of these acknowledgements, multiple segments of data can be sent and acknowledged with a single TCP message in the opposite direction. This acknowledgement contains an ACK number based on the total number of bytes received in the session. For example, starting with a sequence number of 2000, if 10 segments of 1,000 bytes each were received, an ACK number of 12001 would be returned to the source.

The amount of data that a source can transmit before an acknowledgement must be received is called the window size, which is a field in the TCP header that enables the management of lost data and flow control.

A destination host service using TCP usually only acknowledges data for contiguous sequence bytes. If one or more segments are missing, only the data in the first contiguous sequence of bytes is acknowledged. For example, if segments with sequence numbers 1500 to 3000 and 3400 to 3500 were received, the ACK number would be 3001. This is because there are segments with the SEQ numbers 3001 to 3399 that have not been received.

When TCP at the source host has not received an acknowledgement after a predetermined amount of time, it returns to the last ACK number received and retransmits the data from that point forward. The retransmission process is not specified by the Request for Comments (RFC), but instead is left up to the particular implementation of TCP.

For a typical TCP implementation, a host may transmit a segment, put a copy of the segment in a retransmission queue, and start a timer. When the data acknowledgement is received, the segment is deleted from the queue. If the acknowledgement is not received before the timer expires, the segment is retransmitted.

Hosts today may also employ an optional feature called selective acknowledgements (SACKs). If both hosts support SACKs, it is possible for the destination to acknowledge bytes in discontinuous segments and the host would only need to retransmit the missing data.

To accomplish flow control, the first thing that TCP determines is the amount of data segments that the destination device can accept. As previously indicated, the TCP header includes a 16-bit field called the window size. This indicates the number of bytes that the destination device of a TCP session is able to accept and process at one time. The initial window size is agreed upon during the session startup via the three-way handshake between source and destination. Once agreed upon, the source device must limit the amount of data segments sent to the destination device based on the window size. Only after the source device receives an acknowledgement that the data segments have been received can it continue sending more data for the session.

During the delay in receiving the acknowledgement, the sender does not send any additional segments. In periods when the network is congested or the resources of the receiving host are strained, the delay may increase. As this delay grows longer, the effective transmission rate of the data for this session decreases. The slowdown in data transmission from each session helps reduce resource conflict on the network and destination device when multiple sessions are running.

See Figure 5-17 for a simplified representation of window size and acknowledgements. In this example, the initial window size for a TCP session represented is set to 3,000 bytes. When the sender has transmitted 3,000 bytes, it waits for an acknowledgement of these bytes before transmitting more segments in this session. After the sender has received an acknowledgement from the receiver, the sender can transmit an additional 3,000 bytes.

TCP uses window sizes to attempt to manage the rate of transmission to the maximum flow that the network and destination device can support, while minimizing loss and retransmissions.

The receiving host sends the window size value to the sending host to indicate the number of bytes that it is prepared to receive. If the destination needs to slow down the rate of communication because of limited buffer memory, for example, it can send a smaller window size value to the source as part of an acknowledgement.

As shown in Figure 5-18, if a receiving host has congestion, it may respond to the sending host with a segment that specifies a reduced window size. In this figure, there was a loss of one of the segments. The receiver changed the window field in the TCP header of the returning segments in this conversation from 3000 down to 1500, which caused the sender to reduce the window size to 1,500 bytes.

After a period of transmission with no data losses or constrained resources, the receiver begins to increase the window field, which reduces the overhead on the network because fewer acknowledgements must be sent. The window size continues to increase until there is data loss, which causes the window size to decrease.

This dynamic increasing and decreasing of window size is a continuous process in TCP. In highly efficient networks, window sizes may become very large because data is not lost. In networks where the underlying infrastructure is under stress, the window size likely remains small.

This does not mean that applications that use UDP are always unreliable, nor does it mean that UDP is an inferior protocol. It simply means that these functions are not provided by the transport layer protocol and must be implemented elsewhere, if required.

Although the total amount of UDP traffic found on a typical network is often relatively low, key application layer protocols that use UDP include

Domain Name System (DNS)

Simple Network Management Protocol (SNMP)

Dynamic Host Configuration Protocol (DHCP)

Routing Information Protocol (RIP)

Trivial File Transfer Protocol (TFTP)

IP telephony or Voice over IP (VoIP)

Online games

Some applications, such as online games or VoIP, can tolerate some data loss. If these applications used TCP, they could experience large delays while TCP detects data loss and retransmits data. These delays would be more detrimental to the performance of the application than small data losses. Some applications, such as DNS, simply retry the request if no response is received; therefore, they do not need TCP to guarantee message delivery. The low overhead of UDP makes it very desirable for such applications.

Many applications that use UDP send small amounts of data that can fit in one segment. However, some applications send larger amounts of data that must be split into multiple segments. The UDP PDU is referred to as a datagram, although the terms segment and datagram are sometimes used interchangeably to describe a transport layer PDU.

When multiple datagrams are sent to a destination, they may take different paths and arrive in the wrong order. UDP does not track sequence numbers the way TCP does. UDP has no way to reorder the datagrams into their transmission order.

Therefore, UDP simply reassembles the data in the order that it was received and forwards it to the application. If the data sequence is important to the application, the application must identify the proper sequence and determine how the data should be processed.

Randomized source port numbers also help with security. If there is a predictable pattern for destination port selection, an intruder can more easily simulate access to a client by attempting to connect to the port number most likely to be open.

Because there is no session to be created with UDP, as soon as the data is ready to be sent and the ports have been identified, UDP can form the datagrams and pass them to the network layer to be addressed and sent on the network.

After a client has selected the source and destination ports, the same pair of ports is used in the header of all datagrams used in the transaction. For the data returning to the client from the server, the source and destination port numbers in the datagram header are reversed.

This makes TCP best suited for applications that need reliable transport and can tolerate some delay. TCP is a great example of how the different layers of the TCP/IP protocol suite have specific roles. Because the transport layer protocol TCP handles all tasks associated with segmenting the data stream into segments, reliability, flow control, and reordering of segments, it frees the application from having to manage any of this. The application can simply send the data stream to the transport layer and use the services of TCP.

Some examples of well-known applications that use TCP include

HTTP

FTP

SMTP

Telnet

Applications that can tolerate some data loss, but require little or no delay

Applications with simple request and reply transactions

Unidirectional communications where reliability is not required or can be handled by the application

Many video and multimedia applications, such as VoIP and Internet Protocol Television (IPTV), use UDP. These applications can tolerate some data loss with little or no noticeable effect. The reliability mechanisms of TCP introduce some delay that can be noticeable in the quality of the sound or video being received.

Other types of applications well suited for UDP are those that use simple request and reply transactions. This is where a host sends a request and may or may not receive a reply. These types of applications include

DHCP

DNS (may also use TCP)

SNMP

TFTP

Some applications handle reliability themselves. These applications do not need the services of TCP, and can better utilize UDP as the transport layer protocol. TFTP is one example of this type of protocol. TFTP has its own mechanisms for flow control, error detection, acknowledgements, and error recovery. It does not need to rely on TCP for those services.

The transport layer provides transport-related services by

Dividing data received from an application into segments

Adding a header to identify and manage each segment

Using the header information to reassemble the segments back into application data

Passing the assembled data to the correct application

UDP and TCP are common transport layer protocols.

UDP datagrams and TCP segments have headers added in front of the data that include a source port number and destination port number. These port numbers enable data to be directed to the correct application running on the destination computer.

TCP does not pass any data to the network until it knows that the destination is ready to receive it. TCP then manages the flow of the data and resends any data segments that are not acknowledged as being received at the destination. TCP uses mechanisms of handshaking, timers, acknowledgement messages, and dynamic windowing to achieve reliability. The reliability process, however, imposes overhead on the network in terms of much larger segment headers and more network traffic between the source and destination.

If the application data needs to be delivered across the network quickly, or if network bandwidth cannot support the overhead of control messages being exchanged between the source and the destination systems, UDP would be the developer’s preferred transport layer protocol. UDP does not track or acknowledge the receipt of datagrams at the destination; it just passes received datagrams to the application layer as they arrive. UDP does not resend lost datagrams. However, this does not necessarily mean that the communication itself is unreliable; there may be mechanisms in the application layer protocols and services that process lost or delayed datagrams if the application has these requirements.

The application developer decides which transport layer protocol best meets the requirements for the application. It is important to remember that the other layers all play a part in data network communications and influence its performance.

Class Activity 5.3.1.1: We Need to Talk, Again – Game

Lab 5.2.3.5: Using Wireshark to Examine a UDP DNS Capture

Lab 5.2.4.3: Using Wireshark to Examine FTP and TFTP Captures

1. What is the purpose of the transport layer? (Choose two.)

A. It is responsible for
establishing a permanent communication link between two applications and delivering data between them.

B. It is the link between the application layer and the lower layers that is responsible for network transmission.

C. It uses IP information to identify the appropriate application for each communication stream.

D. If necessary, it reassembles segments into the order in which they were sent.

2. How does the transport layer aid in end-to-end communication for applications? (Choose two.)

A. At the source, data is sorted into frames, or conversations.

B. It adds a header to the segment to enable data reassembly.

C. It passes data down to the lower layers as manageable pieces that can be multiplexed, or inserted with other data packets, over the media.

D. At the destination, it sends segments to the presentation layer for reassembly.

3. In TCP/IP, segmentation and reassembly processes can be achieved using which transport layer protocol?

A. IP

B. TCP

C. UDP

D. TFTP

4. What does the transport layer use to track application conversations?

A. Port numbers

B. MAC addresses

C. IP addresses

D. VLAN tags

5. Which statements are true? (Choose two.)

A. TCP is stateful and connectionless.

B. UDP is stateful and connection-oriented.

C. TCP is stateless and connection-oriented.

D. UDP is connectionless and stateless.

E. TCP is connection-oriented and stateful.

F. UDP is stateless and connection-oriented.

6. What is an example of a protocol that uses TCP?

A. IP

B. FTP

C. UDP

D. IPX

7. Which is not true of TCP?

A. Different applications have different reliability requirements.

B. It is used by the IP protocol.

C. It functions at OSI Layer 3.

D. It ensures that all data arrives at its destination.

8. Which is not a function of the transport layer?

A. Tracking transmitted data segments

B. Initiating data streams in the application layer

C. Acknowledging received data

D. Retransmitting any unacknowledged data

9. When a message fails to deliver the first time, how will TCP respond?

A. Resend the message when the user requests it

B. Resend the message when a portion is not acknowledged

C. Resend only the acknowledged segments

D. Resend the unacknowledged segments

10. Which is true about UDP?

A. It lacks the reliability of transport layer processes found in TCP.

B. It is older and rarely preferred to TCP.

C. It resends complete unacknowledged data in a conversation.

D. It resends only unacknowledged segments in a conversation.

11. Which is true about both TCP and UDP?

A. They are easily interchangeable by application developers.

B. Application developers must choose one depending on the characteristics of the application.

C. TCP is better if an application can tolerate data loss.

D. UDP uses slightly more processing overhead than TCP.

12. Which application would be better suited to TCP?

A. Streaming video

B. VoIP

C. Pandora Music

D. Email

13. Which is a feature of TCP?

A. Connectionless

B. Ordered data reconstruction

C. Best-effort delivery

D. Used in music streaming applications

14. Which is a feature of UDP?

A. Connection-oriented conversations by establishing sessions

B. Best-effort delivery

C. Ordered data reconstruction

D. Flow control

15. How many bytes of overhead data are in the TCP data header?

A. 64

B. 32

C. 20

D. 16

E. 8

16. A socket consists of

A. The combination of the source and destination MAC addresses and port numbers

B. The combination of SYN flags and ACK flags

C. The combination of the source and destination IP addresses and port numbers

D. The combination of only the destination IP addresses and MAC addresses

17. In which scenario will the transport layer at the destination use HTTP to retrieve a web page from a web server?

A. The header contains the HTTP port of 110.

B. Port 21 is listed as the source port in the header.

C. The source port in the header is 23.

D. The destination port in the header is 80.

18. Which destination IP address indicates an email application must be used?

A. 172.16.20.10:80

B. 192.168.15.5:110

C. 172.16.4.12:23

D. 192.168.15.78:53

19. What does the flow-control window size indicate?

A. The expected number of bits in each sequence

B. The number of the first acknowledgement number

C. The number of the next expected byte

D. The number of the last byte received

20. With a window size of 2500, what would be the second acknowledgement number sent by the receiver?

A. 2500

B. 2501

C. 2502

D. 5001

21. How does a sender know which segments were not received and need to be re-sent?

A. The three-way handshake

B. The SEQ and ACK messages

C. The window size decreases

D. The window closes for a time

22. Which two statements are likely true when a receiving host adjusts the window size from 2500 to 2000 during transmission? (Choose two.)

A. Static window sizing is in use.

B. The transmission will become more efficient.

C. The transmission time of the complete message will increase.

D. There will be more SEQ and ACK messages.

E. There is a reduction in traffic on the network.

F. The flow of data is stopped while the window size is adjusted.