The transport layer is responsible for establishing a temporary communication session between two applications and delivering data between them. An application generates data that is sent from an application on a source host to an application on a destination host, without regard to the destination host type, the type of media over which the data must travel, the path taken by the data, the congestion on a link, or the size of the network.
The primary responsibilities of transport layer protocols are:
- Tracking the individual communication between applications on the source and destination hosts,
A host may have multiple applications that are communicating across the network simultaneously.
- Segmenting data for manageability and reassembling segmented data into streams of application data at the destination,
- Identifying the proper application for each communication stream (identifier is called a port number).
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.
Multiplexing - feature will allow different communication streams to occur at the same time, without having a single data stream using all available bandwidth
TCP/UDP
With TCP, the three basic operations of reliability are:
- Tracking transmitted data segments (Ordered data reconstruction)
- 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 resent, not the entire message.
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. With UDP, there are no transport layer processes that inform the sender if successful delivery has occurred.
Application developers must choose which transport protocol type is appropriate based on the requirements of the applications.
TCP: reliable, req ACK, resend lost segments, deliver data in order sent;
UDP: fast, low overhead, without ACK, without resend, procceess segment as arrived.
TCP: HTTP, FTP, SMTP, Telnet
UDP: VoIP, DHCP, SNMP, TFTP
Both: DNS
UDP is preferable with applications, such as streaming audio, video, and Voice over IP (VoIP). Acknowledgments would slow down delivery and retransmissions are undesirable.
 |
| TCP Header, image from http://nmap.org/book/tcpip-ref.html |
- 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.
 |
| TCP Header, image from http://nmap.org/book/tcpip-ref.html |
The source port of a client request is randomly generated. This port number acts like a return address for the requesting application.
The Internet Assigned Numbers Authority (IANA) assigns port numbers.
There are different types of port numbers, as shown in Figure 1:
* Well-known Ports (Numbers 0 to 1023) - These numbers are reserved for services and applications. (HTTP, IMAP, SMTP, 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) - 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 used 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.
Netstat is an important network utility that can be used to verify those connections.
Segmentation
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.
Each TCP segment header contains a sequence number that allows the transport layer functions on the destination host to reassemble segments in the order in which they were transmitted.
Information may arrive in a different order than it was transmitted, because different packets may take different paths through the network.
TCP Communication
An individual server cannot have two services assigned to the same port number within the same transport layer services.
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.
TCP 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.
 |
| TCP 3-way handshake |
ACK = Number +1, needed to acknowledge of sent data.
(inital TCP 3-way handshake)To close a connection, the Finish (FIN) control flag must be set in the segment header. To end each one-way TCP session, a two-way handshake is used, consisting of a FIN segment and an ACK segment. Therefore, to terminate a single conversation supported by TCP, four exchanges are needed to end both sessions.
step A: X->Z [SYN] Seq=45 Ack=0 (NULL)
step B: X<-Z [SYN, ACK] Seq=86 Ack=46 (46=seq from step A +1)
step C: X->Z [ACK] Seq=46 Ack=87 (87=seq from step B +1)
(at this point, the connection is established)
(when client sends some data)
step D: X->Z [ACK] Seq=46 Ack=87 Len=6 data='Hello?'
step E: X<-Z [ACK] Seq=87 Ack=52 Len=7 data='Go away'
step F: X->Z [ACK] Seq=52 Ack=94 Len=3 data='No!'
 |
| TCP FIN |
Resequencing Segments
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.
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.
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.
TCP Window Size
TCP Window Size - the amount of data the destination can process at one time.
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.
(window size - source can transmit up to WSIZE xxx bytes of data before it must pause and wait for an acknowledgment).
Window is the number of bytes that the sender will send prior to expecting an acknowledgement from the destination device. The initial window is agreed upon during the session startup via the three-way handshake between source and destination. It is determined by how much data the destination device of a TCP session is able to accept and process at one time.
When a TCP connection is established, each side generates a random number as its initial sequence number. It is a strongly random number: there are security problems if anybody on the internet can guess the sequence number, as they can easily forge packets to inject into the TCP stream.
Example:
OS Windows
For Ethernet networks, the default value is 17520 bytes, or 12 segments of 1,460 bytes each (TCP MSS).
Handling Segment Loss
No matter how well designed a network is, data loss occasionally occurs; therefore, TCP provides methods of managing these segment losses. Among these is a mechanism to retransmit segments with unacknowledged data.
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 is left up to the particular implementation of TCP.
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.
Flow Control
Flow control helps maintain the reliability of TCP transmission by adjusting the rate of data flow between source and destination for a given session.
1)To accomplish flow control, the first thing that TCP determines is the amount of data segments that the destination device can accept.
The TCP header includes a 16-bit field called the window size. This is the number of bytes that the destination device of a TCP session is able to accept and process at one time.
Max bytes = 2^16 = 65536 bytes = 64 KB
2) The initial window size is agreed upon during the session startup via the three-way handshake between source and destination.
3) Only after the source device receives an acknowledgement that the data segments have been received, can it continue sending more data for the session.
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.
Reducing Window Size
Another way to control the data flow is to use dynamic window sizes. When network resources are constrained, TCP can reduce the window size to require that received segments be acknowledged more frequently. This effectively slows down the rate of transmission because the source waits for data to be acknowledged more frequently.
If segment was lost, the receiver changed the window field in the TCP header of the returning segments in this conversation from 3,000 down to 1,500, which caused the sender to reduce the window size to 1,500.
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 acknowledgments 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.
Essentially, window scaling simply extends the 16-bit window field to 32 bits in length.
The window scaling option may be sent only once during a connection by each host, in its SYN packet. The window size can be dynamically adjusted by modifying the value of the window field in the TCP header, but the scale multiplier remains static for the duration of the TCP connection. Scaling is only in effect if both ends include the option; if only one end of the connection supports window scaling, it will not be enabled in either direction. The maximum valid scale value is 14
UDP
UDP is not connection-oriented and does not offer the sophisticated retransmission, sequencing, and flow control mechanisms that provide reliability
It simply means that these functions are not provided by the transport layer protocol and must be implemented elsewhere, if required.
UDP based services:
- 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
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.
Like TCP-based applications, UDP-based server applications are assigned well-known or registered port numbers.