TCP is a connection-oriented, end-to-end protocol that exists as part of the transport layer of the TCP/IP protocol stack, in order to support applications that span over multi-network environments. The transmission control protocol provides a means of reliable inter-process communication between pairs of processes in host computers that are attached to distinct but interconnected computer communication networks. TCP relies on lower layer protocols to provide the reachability between process supporting hosts, over which a reliable connection service is established between pairs of processes. The connection-oriented behavior of TCP involves prior exchanges between the source and destination, through which a connection is established before transport layer segments are communicated.
As a means for allowing for many processes within a single host to use TCP communication facilities simultaneously, TCP provides a set of logical ports within each host. The port value together with the network layer address is referred to as a socket, for which a pair of sockets provide a unique identifier for each connection, in particular where a socket is used simultaneously in multiple connections. That is to say, a process may need to distinguish among several communication streams between itself and another process (or processes), for which each process may have a number of ports through which it communicates with the port or ports of other processes.
Certain processes may own ports and these processes may initiate connections on the ports that they own. These ports are understood as IANA assigned system ports or well-known ports and exist in the port value range of 0 – 1023. A range of IANA assigned user or registered ports also exist in the range of 1024 – 49151, with dynamic ports, also known as private or ephemeral ports in the range of 49152 – 65535, which are not restricted to any specific application. Hosts will generally be assigned a user port value for which a socket is generated to a given application.
Common examples of TCP based applications for which well-known port numbers have been assigned include FTP, HTTP, TELNET, and SMTP, which often will work alongside other well-known mail protocols such as POP3 (port 110) and IMAP4 (port 143).
The TCP header allows TCP based applications to establish connection-oriented data streams that are delivered reliability, and to which flow control is applied. A source port number is generated where a host intends to establish a connection with a TCP based application, for which the destination port will relate to a well-known/registered port to which a well-known/registered application is associated.
Code bits represent functions in TCP, and include an urgent bit (URG) used together the urgent pointer field for user directed urgent data notifications, acknowledgment of received octets in association with the acknowledgement field (ACK), the push function for data forwarding (PSH), connection reset operations (RST), synchronization of sequence numbers (SYN) and indication that no more data is to be received from the sender (FIN). Additional code bits were introduced in the form of ECN-Echo (ECE) and Congestion Window Reduced (CWR) flags, as a means of supporting congestion notification for delay sensitive TCP applications.
The explicit congestion notification (ECN) nonce sum (NS) was introduced as a follow-up alteration to eliminate the potential abuse of ECN where devices along the transmission path may remove ECN congestion marks. The Options field contains parameters that may be included as part of the TCP header, often used during the initial connection establishment, as in the case of the maximum segment size (MSS) value that may be used to define the size of the segment that the receiver should use. TCP header size must be a sum of 32 bits, and where this is not the case, padding of 0 values will be performed.
When two processes wish to communicate, each TCP must first establish a connection (initialize the synchronization of communication on each side). When communication is complete, the connection is terminated or closed to free the resources for other uses. Since connections must be established between unreliable hosts and over the unreliable Internet domain, a handshake mechanism with clock-based sequence numbers is used to avoid erroneous initialization of connections.
A connection progresses through a series of states during establishment. The LISTEN state represents a TCP waiting for a connection request from any remote TCP and port. SYN-SENT occurs after sending a connection request and before a matching request is received. The SYN-RECEIVED state occurs while waiting for a confirming connection request acknowledgment, after having both received and sent a connection request. The ESTABLISHED state occurs following the handshake at which time an open connection is created, and data received can be delivered to the user.
The TCP three-way handshake mechanism begins with an initial sequence number being generated by the initiating TCP as part of the synchronization (SYN) process. The initial TCP segment is then set with the SYN code bit, and transmitted to the intended IP destination TCP to achieve a SYN-SENT state. As part of the acknowledgement process, the peering TCP will generate an initial sequence number of its own to synchronize the TCP flow in the other direction. This peering TCP will transmit this sequence number, as well as an acknowledgement number that equals the received sequence number incremented by one, together with set SYN and ACK code bits in the TCP header to achieve a SYN-RECEIVED state.
The final step of the connection handshake involves the initial TCP acknowledging the sequence number of the peering TCP by setting the acknowledgement number to equal the received sequence number plus one, together with the ACK bit in the TCP header, allowing an ESTABLISHED state to be reached.
Since the TCP transmission is sent as a data stream, every octet can be sequenced, and therefore each octet can be acknowledged. The acknowledgement number is used to achieve this by responding to the sender as confirmation of receipt of data, thus providing data transport reliability. The acknowledgement process however is cumulative, meaning that a string of octets can be acknowledged by a single acknowledgement by reporting to the source the sequence number that immediately follows the sequence number that was successfully received. In the example a number of bytes (octets) are transmitted together before TCP acknowledgement is given. Should an octet fail to be transmitted to the destination, the sequence of octets transmitted will only be acknowledged to the point at which the loss occurred. The resulting acknowledgement will reflect the octet that was not received in order to reinitiate transmission from the point in the data stream at which the octet was lost.
The ability to cumulate multiple octets together before an acknowledgement enables TCP to operate much more efficiently, however a balance is necessary to ensure that the number of octets sent before an acknowledgement is required is not too extreme, for if an octet fails to be received, the entire stream of octets from the point of the loss must be retransmitted.
The TCP window field provides a means of flow control that governs the amount of data sent by the sender. This is achieved by returning a "window" with every TCP segment for which the ACK field is set, indicating a range of acceptable sequence numbers beyond the last segment successfully received. The window indicates the permitted number of octets that the sender may transmit before receiving further permission.
In the example, TCP transmission from host A to server A contains the current window size for host A. The window size for server A is determined as part of the handshake, which based on the transmission can be assumed as 2048. Once data equivalent to the window size has been received, an acknowledgement will be returned, relative to the number of bytes received, plus one. Following this, host A will proceed to transmit the next batch of data.
A TCP window size of 0 will effectively deny processing of segments, with exception to segments where the ACK, RST and URG code bits are set for incoming segments. Where a window size of 0 exists, the sender must still periodically check the window size status of receiving TCP to ensure any change in the window size is effectively reported, the period for retransmission is generally two minutes. When a sender sends periodic segments, the receiving TCP must still acknowledge with a sequence number announcement of the current window size of 0.
As part of the TCP connection termination process, a number of states are defined through which TCP will transition. These states include FIN-WAIT-1 that represents waiting for a connection termination (FIN) request from the remote TCP, or an acknowledgment of a connection termination request that was previously sent. The FIN-WAIT-2 represents waiting for a connection termination request from the remote TCP following which will generally transition to a TIME-WAIT state. A CLOSE-WAIT state indicates waiting for a locally defined connection termination request, typically when a server’s application is in the process of closing.
The LAST-ACK state represents waiting for an acknowledgment of the connection termination request previously sent to the remote TCP (which includes an acknowledgment of its connection termination request). Finally, a TIME-WAIT state occurs and waits for enough time to pass to ensure that the remote TCP received the acknowledgment of its connection termination request. This period is managed by the Max Segment Lifetime (MSL) timer that defines a waiting period of 2 minutes. Following a wait period equal to two times the MSL, the TCP connection is considered closed/terminated.
The User Datagram Protocol, or UDP, represents an alternative to TCP and applied where TCP is found to act as an inefficient transport mechanism, primarily in the case of highly delay sensitive traffic. Where TCP is considered a segment, the UDP is recognized as a datagram form of Protocol Data Unit (PDU), for which a datagram can be understood to be a self-contained, independent entity of data carrying sufficient information to be routed from the source to the destination end system without reliance on earlier exchanges between this source and destination end systems and the transporting network, as defined in RFC 1594. In effect this means that UDP traffic does not require the establishment of a connection prior to the sending of data.
The simplified structure and operation of UDP makes it ideal for application programs to send messages to other programs, with a minimum of protocol mechanism such in the case of acknowledgements and windowing for example, as found in TCP segments. In balance however, UDP does not guarantee delivery of data transmission, nor protection from datagram duplication.
The UDP header provides a minimalistic approach to the transport layer, implementing only a basic construct to help identify the destination port to which the UDP based traffic is destined, as well as a length field and a checksum value that ensures the integrity of the UDP header. In addition the minimal overhead acts as an ideal means for enabling more data to be carried per packet, favoring real time traffic such as voice and video communications where TCP provides a 20 byte overhead and mechanisms that influence delays, such as in the case of acknowledgements, however the lack of such fields means that datagram delivery is not guaranteed.
Since UDP datagram transmission is not sent as a data stream, transmission of data is susceptible to datagram duplication. In addition, the lack of sequence numbers within UDP means that delivery of data transmission over various paths is likely to be received at the destination in an incorrect, non-sequenced order.
Where stream data is transported over UDP such as in the case of voice and video applications, additional protocol mechanisms may be applied to enhance the capability of UDP, as in the case of the real time transport protocol (RTP) which helps to support the inability of UDP by providing a sequencing mechanism using timestamps to maintain the order of such audio/video data streams, effectively supporting partial connection oriented behavior over a connectionless transport protocol.
The general UDP forwarding behavior is highly beneficial to delay sensitive traffic such as voice and video. It should be understood that where a connection-oriented transport protocol is concerned, lost data would require replication following a delay period, during which time an acknowledgement by the sender is expected. Should the acknowledgement not be received, the data shall be retransmitted.
For delay sensitive data streams, this would result in incomprehensible audio and video transmissions due to both delay and duplication, as a result of retransmission from the point where acknowledgements are generated. In such cases, minimal loss of the data stream is preferable over retransmission, and as such UDP is selected as the transport mechanism, in support of delay sensitive traffic.
SUMMARY
The acknowledgement field in the TCP header confirms receipt of the segment received by the TCP process at the destination. The sequence number in the TCP header of the received IP datagram is taken and incremented by 1. This value becomes the acknowledgement number in the returned TCP header and is used to confirm receipt of all data, before being forwarded along with the ACK code bit set to 1, to the original sender.
The three-way handshake involves SYN and ACK code bits in order to establish and confirm the connection between the two end systems, between which transmission of datagrams is to occur.