Read TCP state transitions

Read the process of TCP state transformation, for understanding network programming is very helpful, this article will introduce the TCP state transfer process , but the meaning of each state (total 11) is not covered by this article.

content source : "UNIX Network Programming" the first volume chapter 2.6, if the reader is not very understanding of a knowledge point, please refer to the original text.

TCP Status Transition diagram (state transition diagram)

1. Establishing the connection (Three-way hand shake)

• Active open (passive open): The server must be ready to accept incoming connections, usually done through sockets, bind, and listen.
• Passive open (active Open): The client initiates an active open with connect.

In this article, the Performance Analysis tool (sar-n tcp,etcp 1) command, which can be used to count the number of active and passive open, can reflect the server-side's busy level to some extent.

Gives the client-to-server three handshake process:

1. The server is ready to accept incoming connections, usually through sockets, bind, and listen. (Server: Closed->listen)
2. When the client connects to the server via connect, the client TCP sends a SYN decomposition that tells the server that the customer will send the initial sequence number of the data on the connection to be established. (Client: Closed->syn_sent)
3. The server side must ack The SYN of the customer while sending a SYN to tell the client that the server will send the initial serial number of the data on the connection to be established. (Server: SYN_RECV)
4. The customer must ack the SYN of the server. (Client: syn_sent->established)
5. The server receives an ACK from the customer. (Server: syn_recv->established)

Three-time handshake corresponding to the state transition diagram:

2. Establish the connection (opens simultaneous open at the same time)

Refer to "TCP/IP detailed" Volume one 18th chapter 18.8. This happens at both ends where the SYN is sent almost simultaneously and the two SYN is interleaved in the network. This can happen, but is very rare. This requires the client/service to connect to each other using "two identical ports" so that both parties can actively connect to each other.

For example, an application in host a uses local port 7777 and is actively opened 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.

Give the simultaneous open process:

Give a state transition diagram that is open at the same time:

Description: From the present personal experience, this scenario has not been encountered, but from the understanding of the TCP state transition diagram is an unavoidable part. However, in "TCP/IP detailed" Volume one 18th chapter 18.8 expenditure, many of the Berkeley version of the TCP implementation can not correctly support open.

3. Failed to establish connection (1)

Consider the scenario: the client has not yet received a Ack+syn from the server, exiting unexpectedly. At this point, when the client then receives Ack+syn from the server side, the client replies to RST (reset). When the server is in the SYN_RECV state, which is the RST that is received to the client, it is transferred from SYN_RECV to the listen state.

Specific process:

1. The server is ready to accept incoming connections, usually through sockets, bind, and listen. (Server: Closed->listen)
2. When the client connects to the server via connect, the client TCP sends a SYN decomposition that tells the server that the customer will send the initial sequence number of the data on the connection to be established. Then the client crash. (client: Closed->syn_sent, then suddenly crash, exit Syn_sent)
3. The server side must ack The SYN of the customer while sending a SYN to tell the client that the server will send the initial serial number of the data on the connection to be established. (Server: SYN_RECV)
4. The customer cannot find the socket corresponding to the syn_sent state of the Ack+syn, then responds to RST. (Server: Syn_recv->listen)

Give a diagram of the state transition to establish a connection failure:

4. Failed to establish connection (2)

Consider Scenario 1: The server's process exits unexpectedly and the client does not know. After the client sends the SYN, the server responds to the RST, and the client establishes a connection failure.

Consider Scenario 2: The server's machine shuts down and the server IP is unreachable. After the client sends the SYN, the time-out is re-sent, more than the retry count, and finally timeout, the client fails to establish the connection.

Specific process:

1. Assume that the server process exits. (Server: listen->closed)
2. When the client connects to the server via connect, the client TCP sends a SYN decomposition that tells the server that the customer will send the initial sequence number of the data on the connection to be established. (Client: Closed->syn_sent)
3. Server side receives client SYN, Response rst (server: CLOSED)
4. The customer receives the RST. (Client: syn_sent->closed)

Give a diagram of the state transition to establish a connection failure:

5. Disconnect (four waves)

• Active Close: An application first calls close and sends a FIN packet.
• Passive shutdown (passive close): A passive shutdown is performed on the peer receiving the fin.

Give the client and server a four-time wave process:

1. An application first calls Close, which sends a FIN packet, indicating that the data has been sent, and that the application has no more data sent to the peer. (for example, if the HTTP server sends reponse data to the client, no additional data is sent, the server can perform an active shutdown) (active: established->fin_wait_1)
2. Accepts a passive shutdown of the peer to fin. First, the received FIN packet is ack. The receive of the fin packet is also passed as a file terminator (EOF) to the application (after any other data that has been queued for the application process), because the fin package means that the receiving application process has no additional data to receive on the corresponding connection. (Passive side: established->close_wait, active end: fin_wait_1->fin_wait_2)
3. After some time, the application process receiving this EOF will call close to close his socket. This causes its TCP to also send a fin packet. (Passive side: close_wait->last_wait)
4. Receive this final fin by performing an active shutdown on the end of the ACK of this fin. (Passive side: last_wait->closed, active: fin_wait_2->time_wait (after 2MSL, time_wait->closed))

Give a four-time wave of the state transition diagram:

6. Disconnect (closes simultaneous close at the same time)

Refer to "TCP/IP detailed" Volume one 18th chapter 18.9. We have discussed before that one party (usually but not always client side) sends the first fin to perform an active shutdown. It is also possible for both parties to perform a proactive shutdown, and the TCP protocol allows such a simultaneous shutdown (simultaneous close).

Give the simultaneous shutdown process:

Give a state transition diagram that is closed at the same time:

7. Disconnect (in Fin_wait_1 state, receive Fin+ack)

Consider the scenario: the passive closed end received fin packet, directly send Fin+ack, then the active closed side from fin_wait_1 Skip fin_wait_2, directly into the time_wait.

Give the specific process:

1. An application first calls Close, which sends a FIN packet, indicating that the data has been sent, and that the application has no more data sent to the peer. (for example, if the HTTP server sends reponse data to the client, no additional data is sent, the server can perform an active shutdown) (active: established->fin_wait_1)
2. Accepts a passive shutdown of the peer to fin. After receiving the fin package, the passive side calls close to close the socket, then the fin+ack is sent to the active side. (Passive side: Established->close_wait->last_ack, active end: fin_wait_1->time_wait)
3. Receive this final fin by performing an active shutdown on the end of the ACK of this fin. (Passive side: last_wait->closed, active: fin_wait_2->time_wait (after 2MSL, time_wait->closed))

Give a state transition diagram that is closed at the same time:

Reference:

1. The first volume of UNIX Network programming chapter 2nd
2. The 18th chapter of "TCP/IP detailed" Volume One

Description (Key Note):

1. "UNIX Network Programming" the first volume (third edition) Figure 2.4 There is an error, when the server transfers from listen to SYN_RCVD, the condition should be "receive: SYN; send: Syn,ack" instead of "receive: RST; send: Syn,ack". This can be seen from the original picture of English.
2. I also think that in the TCP state transition diagram in the book, the condition that SYN_RCVD transfers to listen should be server state , not client state .

Author Description:

Limited to my understanding of certain technical points (although also looked at a lot of information), may be expressed in some places is not very accurate, please advise, contact information for [email protected].

Read TCP state transitions