TCP State Transitions

TCP is a connection-oriented protocol that must establish a connection between the two parties, regardless of which direction the other party sends the data. This section discusses in detail how a TCP connection is established and how it terminates after the communication has ended.
Establish a TCP connection
TCP uses the three-time handshake (Three-way Handshake) Protocol to establish the connection, and figure 3-10 describes the three-handshake message sequence. These three handshakes are:
The requesting side (often referred to as the client) sends a SYN segment (SYN 1) indicating the port of the server to which the customer intends to connect, and the initial sequence number (ISN).
The server sends back a SYN message segment (SYN 1) that contains the initial sequence number of the server. At the same time, the confirmation number is set to the customer's ISN plus 1 to confirm the customer's SYN segment (ACK is also 1).
The customer must set the confirmation number to the server's ISN plus 1 to confirm the SYN segment of the server (ACK 1), which informs the destination host that the two sides have completed the connection establishment.
Sending one end of the first SYN will perform the active open (active open), receiving this SYN and returning to the other side of the next SYN to perform a passive open (passive open). In addition, the TCP handshake protocol is carefully designed to handle simultaneous opening (simultaneous open), which establishes only one connection, not two connections, for simultaneous opening. Therefore, the connection can be initiated by either party or both parties, and once the connection is established, the data can flow in two directions, without the so-called master-slave relationship.
The three-time handshake protocol is the necessary and sufficient condition for connecting both ends correctly. Because TCP is based on unreliable packet transport services, messages may be lost, delayed, duplicated, and scrambled, so the protocol must use timeouts and retransmission mechanisms. A problem occurs if the retransmission connection request and the original connection request arrive when the connection is being established, or if a deferred connection request arrives after a connection has been established, used, and ended. Using a three handshake protocol (plus a rule: TCP does not ignore another connection request after the connection is established) can solve these problems.

The three-time handshake protocol accomplishes two important functions: it ensures that the connection is ready for transmission and that the initial sequence number is unified by both parties. The initial order number is the transmission sequence number during the handshake and confirmation: When one end sends its SYN to establish a connection, it chooses an initial sequence number for the connection; Each message segment includes a Sequence number field and a confirmation Number field, which allows the two machines to negotiate the sequence number of their data streams using only three handshake messages. In general, ISN varies over time, so each connection will have a different ISN.

turn off a TCP connection
Once a TCP connection is established, data flows can be transmitted in two directions. When the TCP application process no longer has data to send, the Shutdown command is issued. TCP closes the local data stream by sending a control bit fin=1 data slice, but can continue to receive data until the other side closes the data stream in that direction and the connection closes.
The TCP protocol closes the connection using the modified three handshake protocol, as shown in Figure 3-11, which terminates a connection through 4 handshakes. This is due to a half shutdown of TCP (half-close). Because a TCP connection is Full-duplex (that is, the data can be passed in two directions at the same time), each direction must be closed individually. The principle of closure is to send a FIN to terminate this direction when one party completes its data sending task. When one end receives a FIN, it must inform the application layer that the other end has terminated the data transfer in that direction. Sending a FIN is usually the result of a shutdown of the application tier.
From one side of TCP, there are three types of connection closures:
• This side starts off
After receiving the shutdown command of the application process, TCP sends the message segment of the FIN = 1 to the other party after the message segment has not been processed, and TCP no longer accepts the data sent by the application process of the party. The data bytes sent before the fin, including the fin, need to be confirmed by the other side, or they will be transmitted again. Note that FIN also takes up a sequence number. Upon receipt of the other's confirmation of the fin and the fin segment of the other side, TCP confirms the fin, waits for some time, and then closes the connection. Wait is to prevent the side of the confirmation message loss, to avoid the other side of the retransmission message to interfere with the new connection.
• Each other starts off
When TCP receives the fin message from the other side, the ACK confirms the fin message and notifies the application that the connection is shutting down. The application process will respond with a shutdown command. TCP sends a FIN message to the other TCP after the message segment has not been processed, then waits for the other side to confirm the fin, and then closes the connection after receiving confirmation. If the other party's confirmation does not arrive in time, after waiting for some time also closes the connection.
• Both sides start off at the same time
When the application process of the connecting parties sends off the command at the same time, TCP sends the FIN message after the message segment has not been processed. All parties TCP in the fin before the text is confirmed, send an ACK to confirm it received fin. The parties are also waiting for a period of time to close the connection after receiving confirmation from each other about the FIN. This is called simultaneous shutdown (simultaneous close).

TCP State Machine The operation of the TCP protocol can be represented by a finite state machine (finite state Machine) with 11 states, figure 3-12 describes the TCP finite state machine, the rounded rectangle in the graph represents the state, the arrow represents the transition between States, and the description of each state is shown in table 3-2. A bold line in the figure shows the normal process of establishing a connection between the client's active and passive server-side: The client's state transition with the thick solid line, the server-side state transition with a dashed line. Thin lines are used for uncommon sequences, such as resetting, opening at the same time, and closing simultaneously. The events/actions are marked on each state transformation line in the diagram: An event is when a user performs a system call (CONNECT, LISTEN, SEND, or close), receives a message segment (SYN, FIN, ACK, or RST), or has more than twice times the largest group lifetime Action is to send a message segment (SYN, FIN or ACK) or nothing (with "-").
Each connection starts in the CLOSED state. When a party performs a passive connection primitive (LISTEN) or an active connection primitive (connect), it is detached from the CLOSED state. If the other party executes the corresponding connection primitive at this time, the connection is established and the State becomes established. Either party may first request the release of the connection, and when the connection is released, the state is returned to the CLOSED.

1. Normal state conversionWe use Figure 3-13 to show the different states that customers and servers experience during the establishment and termination of normal TCP connections. These states are: Listen,syn-sent,syn-received,established,fin-wait-1,fin-wait-2,close-wait,closing,last-ack,time-wait and CLOSED.


Closed indicates no connection, and the meanings of each state are as follows:
LISTEN-listens for connection requests from a remote TCP port;
Syn-sent-waits for a matching connection request after sending a connection request;
Syn-received-Waits for confirmation of the connection request after receiving and sending a connection request;
Established-represents an open connection in which data can be transmitted to the user;
Fin-wait-1-Waits for a remote TCP connection interrupt request, or confirmation of a previous connection interrupt request;
Fin-wait-2-Wait for connection interrupt request from remote TCP;
Close-wait-Waits for a connection interrupt request from a local user;
CLOSING-Waits for the remote TCP to confirm the connection interrupt;
Last-ack-Waits for confirmation of the connection interrupt request that originally sent to remote TCP;
Time-wait-wait enough time to ensure that remote TCP receives a confirmation of a connection interrupt request;
CLOSED-no connection status;

The server side first executes the LISTEN primitives into the passive open state (LISTEN), waits for the client to connect;
When one of the client's applications issues a connect command, the local TCP entity creates a connection record for it and marks it as a SYN SENT state, and then sends a SYN segment to the server;
The server receives a SYN segment, and its TCP entity sends a SYN signal to the client to send an ACK message and enters the SYN RCVD state;
The client receives the SYN + ACK message segment, and the TCP entity sends the last ACK message segment of the three handshake to the server side, and converts it to established state;
The server side received a confirmed ACK message segment, completed three handshake, so also entered the established state.
In this state, both parties are free to transmit data. When an application completes a data transfer task, it needs to turn off the TCP connection. Assume that the client still initiates the active shutdown of the connection.
The client executes the close primitive, and the local TCP entity sends a fin segment and waits for the acknowledgment of the response (into the state FIN wait 1);
The server receives a FIN segment, which confirms that the client's request sends back an ACK message segment and enters the close-wait state;
The client receives a confirmation ACK message segment and transfers it to the FIN Wait 2 state, at which point the connection is disconnected in one direction;
When the server-side application is notified, the close primitive is also executed to turn off the connection in another direction, and its local TCP entity sends a FIN segment to the client and enters the last ACK state, waiting for the final ACK acknowledgement message segment;
The client receives the FIN message segment and confirms that it enters the TIMED wait state, at which point the connection has been disconnected, but TCP waits for a maximum lifetime of twice message segments MSL (Maximum Segment Lifetime) to ensure that all packets of the connection disappear to prevent A confirmation loss occurred. When the timer times out, TCP deletes the connection record and returns to the initial state (CLOSED).
The server receives the last acknowledgment ACK segment, and its TCP entity releases the connection and deletes the connection record, returning to the initial state (CLOSED).

2. Open at the same time: Although the probability of occurrence is very small, it is possible for two applications to perform active open at the same time. Each party must send a SYN, and the SYN must be passed on to each other. This requires each party to use a well-known port as the local port. For example, one application in host a uses local port 7777 and actively opens with port 8888 of host B. The application in host B uses local port 8888 and is actively opened with Port 7777 of host A. TCP is designed so that it can be processed at the same time, and that it only establishes one connection instead of two connections (the other protocol family, the most prominent of which is the OSI Transport layer), in which case the two connections will be established instead of a single connection.
When a simultaneous opening occurs, the state transitions are different from those shown in Figure 3-13. Both ends are almost at the same time sending SYN, and entering the syn_sent state. When each end receives SYN, the state becomes SYN_RCVD, and they all send SYN and confirm the received Syn. When both sides receive SYN and the corresponding ACK, the state changes to established. Figure 3-14 shows these state transition processes.
An open connection requires an exchange of 4 message segments, one more than the normal three handshake. Also, note that we do not refer to either end as a client or server because each end is both a client and a server.

3. Simultaneous shutdown: Normally, a party (usually but not always the client) sends the first FIN to perform the active shutdown, but it is also possible for both parties to perform the active shutdown, and the TCP protocol also allows such simultaneous shutdown.
In Figure 3-12, when both ends of the application layer issue a shutdown command, both ends change from established to fin_wait_1. This will cause each side to send a fin, two fin after the network transfer to the other end. After receiving the FIN, the state changes from fin_wait_1 to CLOSING and sends the final ACK. When the last ACK is received, the state changes to time_wait. Figure 3-15 summarizes the changes in these states, as you can see from the diagram that the number of message segments exchanged is the same between closing and normal shutdown use.

4. Other circumstances:The service side opens: The transition from LISTEN to syn_sent is correct, and it sends the SYN message segment on the server side, but the Berkeley version of the TCP software does not support it.
Reset Connection (reset): The state transition from SYN_RCVD to LISTEN is valid only if the SYN_RCVD state is entered from the LISTEN State (normal), rather than from the Syn_sent state (open simultaneously). This means that if we perform a passive open (enter LISTEN), receive a SYN, send a ACK syn (enter SYN_RCVD), and then receive a RST instead of an ACK, then return to the LISTEN state and wait for another connection request to arrive.
Fast shutdown: After the active shutdown of the fin_wait_1 state, if the received message segment is not only ACK, but also include the other side FIN signal, then directly into the TIME_WAIT state, send the other ACK message segment, and then wait for timeout.
In addition, the wait timeout for the time_wait state needs to be explained in more detail because it directly affects the performance of the network application.
Each specific TCP implementation must select a segment maximum lifetime MSL (Maximum Segment Lifetime), which is the longest time in the network before any message segments are discarded. We know that this time is limited because the TCP segment is transmitted over the network with an IP datagram, and the IP datagram has a TTL field that restricts its time to live. RFC 793 [Postel 1981c] indicates that the MSL is 2 minutes. However, the common values in the implementation are 30 seconds, 1 minutes, or 2 minutes.
For a specific implementation of the MSL value given, the principle of processing is: When TCP performs an active shutdown, concurrent back to the last ACK, the connection must stay in the TIME_WAIT state for twice times the MSL, so the TIME_WAIT state is also known as the 2MSL wait state. During this time, if the last ACK is lost, the other party will timeout and resend the last FIN, so that local TCP can send the ACK segment again (this is the only message it can send and reset the 2MSL timer).
Another result of this 2MSL wait is that this TCP connection defines the socket (socket, IP address and port number of the client, and the IP address and port number of the server) for this connection to be used during the 2MSL wait. This connection can only be used again after the end of the 2MSL. Any late message segments are discarded when the connection is at 2MSL waiting.
　　We assume that in Figure 3-12 the customer performs an active shutdown and enters the time_wait, which is normal because the server usually performs a passive shutdown and does not enter the TIME_WAIT state. This implies that if we terminate a client program and immediately restart the client, the new client will not be able to reuse the same local port. This is not a problem because the customer uses the local port and does not care what the port number is. However, for servers, the situation is different because the server uses a well-known port. If we terminate an already connected server program and try to restart the server immediately, the server program will not be able to assign its well-known port to its endpoint because that port is part of the 2MSL connection. It needs to be in 1-4 minutes before restarting the server program. This is the reason that many Web server programs are not able to reboot immediately after they are killed (the error message is "Address already in use").