TCP 3-way hand shake
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 synchronize 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.
- SYN flag set to validate an Initial Sequence Number.
- Randomized ISN valid
- Random source port
- Well-known destination port
Step 2: The server acknowledges the client-to-server communication session and requests a server-to-client communication session.
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 acknowledgment 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 acknowledgment number field is equal to the ISN plus 1 because of the phantom byte, 101=100+1. Also notice that TCP Acknowledgement number specifies the sequence number of the next segment expected by the receiver. In this example, acknowledgement number in step 2 equals the sequence number in step 3. This is called expectational acknowledgement.
Expectational acknowledgement: 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.
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 (Radomly generate its own ISN). 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.
Note. During the TCP startup and teardown sequence, a “phantom byte” causes the sequence number and acknowledgment number fields to increment by 1 even though no data is exchanged. This phantom byte can be confusing when you have just learned that the sequence number field increments only when data is sent.
Step 3: The initiating client acknowledges the server-to-client communication session.
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 acknowledgment 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 the figure, 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
For example, host want to view a webpage from server, after 3-way handshake, Now, someone might be expecting the next packet to be sent from the Server, but this is not the case. You might recall that Host initiated the connection because it wanted to download a web page from the Gateway Server. Since the 3-way TCP handshake has been completed, a virtual connection between the two now exists and the Server is ready to listen to Host’s request.
With this in mind, it’s now time for Host A to ask for the webpage it wanted, go to the data transfer.
Data transfer in TCP
In this step, Host A generates a packet with some data and sends it to the Server. The data tells the Server which webpage it would like sent.
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 the figure, 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.
windows size( Flow control )
Flow control is accomplished by limiting the amount of data segments forwarded at one time and by requiring acknowledgments of receipt prior to sending more.
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.
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 the figure for a simplified representation of window size and acknowledgements. In this example, the initial window size for a TCP session represented is set to 3000 bytes. When the sender has transmitted 3000 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 3000 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.
Dynamic 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.
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 the figure, 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 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.
Datalose and retransmission
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 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 acknowledgment is received, the segment is deleted from the queue. If the acknowledgment 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.
4-way TCP session termination analysis
The termination process can be initiated by any two hosts that have an open session:
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 acknowledgment 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.