TCP status Converter

TCP status Converter
Establishing a TCP connection TCP is a connection-oriented protocol. Before sending data to the other party, a connection must be established between the two parties. This section describes in detail how a TCP connection is established and how it is terminated after the communication ends.
TCP uses the three-way handshake protocol to establish a connection. Figure 3-10 describes the sequence of three-way handshakes. The three handshakes are:
The requester (usually called the customer) sends a SYN packet segment (SYN is 1) indicating the port of the server to which the customer intends to connect and the initial sequence number (ISN ).
The server sends back the SYN packet segment containing the server's initial sequence number (SYN is 1) as the response. At the same time, set the confirmation number to the customer's ISN plus 1 to confirm the customer's SYN packet segment (ACK is also 1 ).
The customer must set the confirmation number as ISN plus 1 of the server to confirm the SYN packet segment of the server (ACK is 1). The message notifies the target host that the connection has been established.

The three-way handshake protocol is a sufficient condition for correct synchronization between the two ends of the connection. Because TCP is built on an unreliable group transmission service, packets may be lost, delayed, duplicated, and out of order. Therefore, the Protocol must use the timeout and retransmission mechanisms. If the retransmission connection request and the original connection request arrive when the connection is being established, or a delayed connection request arrives after a connection has been established, used, and ended, the problem may occur. The three-way handshake protocol (with such a rule: After a connection is established, TCP will ignore another connection request) can solve these problems.
The three-way handshake protocol can complete two important functions: it ensures that both parties are ready for transmission and the initial sequence number is unified. The initial sequence number transmits the sequence number during the handshake and is confirmed: when one end sends its SYN to establish a connection, it selects an initial sequence number for the connection; each packet segment includes the sequence number field and the validation number field, so that the two machines can negotiate the sequence number of their data streams with only three handshake packets. In general, ISN changes over time, so each connection will have a different ISN.
Close a TCP connection
After the TCP connection is established, data streams can be transmitted in two directions. When no data needs to be sent by the TCP application process, the command is closed. TCP closes the local data stream by sending data slices with the control bit FIN = 1, but it can continue to receive data until the other party closes the data stream in that direction, and the connection is closed.
TCP uses the modified three-way handshake protocol to close the connection, as shown in Figure 3-11. That is, it takes four handshakes to terminate a connection. This is caused by the semi-close of TCP. Since a TCP connection is full-duplex (that is, data can be transmitted simultaneously in both directions), each direction must be closed separately. The principle of disabling is that when one party completes its data sending task, it can send a FIN to terminate the connection in this direction. When one end receives a FIN, it must notify the other end of the application layer that the data transfer in that direction has been terminated. Sending FIN is usually the result of disabling the application layer.

For one party's TCP, there are three cases of connection closure:
Disable local startup
After receiving the command for disabling the local application process, TCP sends a FIN = 1 packet segment to the peer end after the unprocessed packet segment is sent, TCP no longer accepts data sending from the local application process. Data bytes sent before FIN, including FIN, must be confirmed by the other party; otherwise, data must be retransmitted. Note that FIN also occupies a sequence number. Once the other party receives the FIN confirmation and the other party's FIN packet segment, the local TCP will confirm the FIN, wait for a while, and then close the connection. The wait is to prevent the loss of the validation message of the local Party and prevent the re-transmission message of the other party from interfering with the new connection.
The other party starts and closes
When TCP receives the FIN message from the other party, it sends an ACK to confirm the FIN message and notifies the application process that the connection is being closed. The application process will close the command response. After TCP sends an unprocessed packet segment, it sends a FIN packet to the peer TCP, waits for the Peer to confirm the FIN, and closes the connection after receiving the confirmation. If the recipient's confirmation does not arrive in time, the connection will be closed after a period of time.
Both parties start and close at the same time
When the application process of both parties simultaneously sends a close command, TCP of both parties sends the FIN packet after the unprocessed packet segment is sent. After the packets sent by TCP before FIN are confirmed, an ACK is sent to confirm the FIN received by TCP. After receiving the confirmation from the other party on FIN, the parties also wait for a while before closing the connection. This is called simultaneous close ).
TCP State Machine
TCP operations can be represented by a Finite State Machine with 11 States. Figure 3-12 describes the Finite State Machine of TCP, And the rounded rectangle in the figure shows the State, arrows indicate the transition between States. descriptions of each State are shown in Table 3-2. In the figure, the normal process of establishing a connection between the client and the passive server is indicated by a thick line: the client status changes with a thick line, and the server status changes with a thick dotted line. A fine line is used for uncommon sequences, such as resetting, enabling, and disabling at the same time. Each status change line in the figure is marked with "event/Action": the event indicates that the user has performed a system call (CONNECT, LISTEN, SEND, or CLOSE), receives a packet segment (SYN, FIN, ACK or RST), or has more than twice the maximum group life cycle; an action refers to sending a packet segment (SYN, FIN, or ACK) or nothing (expressed ).

Figure 3-12 TCP Finite State Machine. Indicates the normal path of the customer;
The thick dotted line indicates the normal path of the server, and the thin line indicates unusual events.
Each connection starts in the CLOSED status. When one party executes the passive connection primitive LISTEN or the active connection primitive CONNECT, it will be out of the CLOSED state. If the other party executes the corresponding connection primitive, the connection is ESTABLISHED and the status changes to ESTABLISHED. Either party can first request to release the connection. When the connection is released, the status returns to CLOSED.
Table 3-2 The TCP status table State describes the CLOSED status of CLOSED. The server is waiting for the connection to enter syn rcvd and receives a connection request, the syn sent has not been confirmed to have SENT a connection request. WAIT for confirmation that the ESTABLISHED connection has been ESTABLISHED. The normal data transmission status fin wait 1 (Active close) has SENT a closing request, and WAIT for confirmation that fin wait 2 (Active close) after receiving the CLOSE confirmation from the other party, WAIT for the other party to CLOSE the request timed wait to complete two-way CLOSE. WAIT for both parties to CLOSE the closed group and WAIT for the other party to confirm closing wait (passive CLOSE) to receive the CLOSE request from the other party, the last ack has been confirmed. Wait until the last ack is confirmed and wait until all groups die. normal status conversion
We use Figure 3-13 to show the different states that customers and servers experience during the establishment and termination of normal TCP connections. You can refer to Figure 3-12 and use the status chart 3-12 to track the status change process in Figure 3-13 so that you can understand the changes in each status: the server first executes the LISTEN primitive to enter the passive open state (LISTEN) and waits for the client to CONNECT. When an application of the client issues the CONNECT command, the local TCP entity creates a connection record for it and marks it as syn sent, and then sends a SYN packet segment to the server. The server receives a SYN packet segment, the TCP entity sends an ACK packet segment to the client and sends a SYN signal to the syn rcvd status. The client receives the SYN + ACK packet segment, the TCP entity sends the last ACK packet segment of the three-way handshake to the server and converts it to the ESTABLISHED status. The server receives the confirmed ACK packet segment and completes the three-way handshake, so it also enters the ESTABLISHED status. In this status, both parties can transmit data freely. When an application completes the data transmission task, it needs to close the TCP connection. Assume that the connection is still actively closed by the client. When the client executes the CLOSE primitive, the local TCP entity sends a FIN packet segment and waits for the response confirmation to enter the fin wait 1 status. The server receives a FIN packet segment, it confirms that the request from the client sends back an ACK packet segment and enters the close wait Status. When the client receives the ACK packet segment, it switches to the fin wait 2 status. At this time, the connection is disconnected in one direction; after the server application is notified, the CLOSE primitive is also executed to CLOSE the connection in another direction. The local TCP entity sends a FIN packet segment to the client and enters the last ack status, WAIT for the last ACK message segment to be confirmed. The client receives and confirms the FIN message segment and enters the timed wait Status. At this time, both parties are disconnected, however, TCP needs to wait for a Maximum survival time MSL (Maximum Segment Lifetime) of a 2x packet Segment to ensure that all groups of the connection disappear to prevent the loss confirmation. When the timer times out, TCP deletes the connection record and returns it to the Initial State (CLOSED ). When the server receives the last ACK message segment, its TCP entity releases the connection, deletes the connection record, and returns the initial status (CLOSED ).
2. enable both:
Despite the minimal likelihood, it is still possible for two applications to actively open each other at the same time. Each party must send a SYN and the SYN must be transmitted to the other party. This requires each Party to use the port of the Peer region as the local port. For example, an application in host A uses the local port 7777 and actively opens it with port 8888 of host B. The application in host B uses the local port 8888 and actively opens it with port 7777 of host. TCP is specially designed to be able to process and open at the same time. For open at the same time, only one connection is established instead of two connections (the OSI transport layer is the most prominent of other protocol families, in this case, two connections will be established instead of one connection ).
The status change is different from the one shown in Figure 3-13 when the function is enabled at the same time. Both ENDS send SYN almost simultaneously and enter the SYN_SENT state. When each end receives SYN, the state changes to SYN_RCVD, and both of them send SYN and confirm the received SYN. When both parties receive SYN and corresponding ACK, the status changes to ESTABLISHED. Figure 3-14 shows the status change process. Figure 3-14 packet segment switching when both are enabled
　
A connection that is opened at the same time needs to exchange four packet segments, one more than a normal three-way handshake. In addition, we did not call any end a customer or server, because each end is both a customer and a server.
3. disable both:
Under normal circumstances, either party (usually but not always the customer) sends the first FIN to execute active shutdown, but it is also possible for both parties to execute active shutdown, the TCP protocol can also be disabled at the same time.
In Figure 3-12, when both ends of the application layer issue a close command at the same time, both ends change from ESTABLISHED to FIN_WAIT_1. This will cause both parties to send one FIN, and the two FIN reach the other end after the network transmission. After receiving the FIN, the status changes from FIN_WAIT_1 to CLOSING and the last ACK is sent. When the last ACK is received, the status changes to TIME_WAIT. Figure 3-15 summarizes the changes in these statuses. It can be seen that the number of packet segment exchanges used for both shutdown and normal shutdown is the same. Figure 3-15 disable packet segment switching during the same time
4. Other cases:
Open by the service provider: the change from LISTEN to SYN_SENT is correct. The server actively sends SYN packets, but the TCP software of Berkeley does not support it.
Reset connection: only when SYN_RCVD enters from the LISTEN status (normal) rather than from the SYN_SENT status (enabled at the same time, the change from SYN_RCVD to LISTEN is effective. This means that if we perform passive open (entering LISTEN), receive a SYN, send a SYN with ACK (entering SYN_RCVD), and then receive an RST instead of an ACK, then return to the LISTEN status and wait for the arrival of another connection request.
Fast shutdown: FIN_WAIT_1 status after active shutdown. If the received packet segment is not only ACK, but also contains the FIN signal of the other party, it enters the TIME_WAIT status directly, send an ACK packet to the other party and wait for timeout.
In addition, the wait timeout of the TIME_WAIT status needs to be explained in detail, because it directly affects the performance of network applications.
For each specific TCP implementation, You must select a Maximum message Segment survival time MSL (Maximum Segment Lifetime), which is the Maximum time in the network before any message Segment is discarded. We know that this time is limited, because the TCP packet segment is transmitted in the network as an IP datagram, And the IP datagram has a TTL field that limits its survival time. RFC 793 [Postel 1981c] indicates that MSL is 2 minutes. However, the common values in the implementation are 30 seconds, 1 minute, or 2 minutes.
For a specific implementation of the given MSL value, the processing principle is: when TCP executes an active close, concurrent back to the last ACK, the connection must be in the TIME_WAIT status for two times of MSL. Therefore, the TIME_WAIT status is also called the 2MSL wait status. During this period, if the last ACK is lost, the other party will time out and resend the final FIN, so that the local TCP can send the ACK packet segment again (this is also the only packet that can be sent, and reset the 2MSL timer ).
Another result of 2MSL wait is that the TCP connection defines the socket of the Connection during 2MSL wait (socket, Client IP address and port number, Server IP address and port number) it cannot be used again. This connection can only be used after 2MSL is completed. When the connection is in 2MSL wait, any late packet segment will be discarded.
We assume that in Figure 3-12, the customer takes the initiative to shut down and enters TIME_WAIT. This is normal because the server normally performs passive shutdown and does not enter the TIME_WAIT status. This implies that if we terminate a customer program and immediately restart the customer program, the new customer program will not be able to reuse the same local port. This will not cause any problems because the customer uses the local port and does not care about the port number. However, for the server, the situation is different because the server uses the accept port. If we terminate a server program that has established a connection and try to restart the server program immediately, the server program will not assign this listener port to its endpoint, because the port is part of the 2MSL connection. Before restarting the server program ~ 4 minutes. This is why many network server programs cannot be restarted immediately after they are killed (the error message is "Address already in use ").