Reasons for the presence of close_wait state in TCP

Close_wait occurs because the peer does not detect the error (the other is disconnected) without invoking the closesocket after the network connection is disconnected, causing the presence of this state.

Simulate such an environment: server 192.168.1.112:4500 After a connection to a client, hibernate five seconds after the server shut down and client communication socket normal exit, and the client after connecting the server, wait for the user input characters, sent to the client. Here are a few questions:

1. After five seconds of hibernation, the server normally exits, but because the client is still waiting for user input, what is the state of TCP on the server side? (fin_wait_2), what is the TCP state of the client? (close_wait)

2. The server in hibernation five seconds, normal exit, after the server exits, if the client exits abnormally, then server-side TCP status is what. What is the TCP state of the client?

After the normal exit of the server, the client exits unexpectedly, then the client sends the RST flag to the server, and then the TCP state on both the client and server side is CLOSED

3. The server in hibernation five seconds after the normal exit, after the server exit, from the client input data, send to the server, at this time the server how to deal with this data?

The client sends data to the server segment through the PSH flag, and can send success, but because the server's TCP is in the (fin_wait_2) state, the server sends a RST mark to the client, and the server port State and the client's TCP state become CLOSED.

4. What is the server-side TCP status when the server is dormant, killing the server process? What is the TCP state of the client? During server hibernation, the server process is killed, at which point the server sends a RST flag to the client, the server TCP state is CLOSED, and the TCP state of the client is close.   After the server is dormant for five seconds, if you do not shut down the socket that communicates with the client directly, the server side also sends the RST sign to the client at this point. For the above four issues, it must be noted that when the server is properly disconnected, the fin sent to the client cannot be handled properly by the client because the client is in the receiving user's input. So because every time the server is actively disconnected, but the server TCP state may not be able to enter the TIME_WAIT state.  Interested can study the following third question, to see under what circumstances, the server can enter into the TIME_WAIT state. (After the normal exit of the server, the client also then normal exit, the server TCP will enter the TIME_WAIT state)