11 States of TCP and problem handling methods

11 states of TCP

All 11 states

1. Clients are unique: (1) syn_sent (2) fin_wait1 (3) fin_wait2 (4) CLOSING (5) time_wait.

2. Unique to the server: (1) LISTEN (2) SYN_RCVD (3) close_wait (4) Last_ack.

3. Common: (1) CLOSED (2) established.

the meaning of each state is 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-Waiting for a remote TCP connection interrupt request, or confirmation of a previous connection interrupt request,
Fin-wait-2-Waiting for a connection interrupt request from a remote TCP; 
close-wait-Waits for a connection interrupt request from a local user; 
CLOSING-Waits for a remote TCP to confirm the connection interrupt, 
Last-ack-waits for the confirmation of the connection interrupt request originally sent to the remote TCP, 
time-wait-waits enough time to ensure that the remote TCP receives the acknowledgement of the connection interrupt request; 
CLOSED-no connection status;

Each state detailed: Listening: Listens for connection requests from a remote TCP port.

First, the server needs to open a socket for listening, the status of listen.
provide a service to be in the listening state, TCP state change is a port state change, provide a service to open a port, for example: the provision of WWW service by default is 80 port, provide FTP service default port is 21, The provided service is in a listening state when it is not connected. The FTP service is first in the listening (listening) state after it is started. While in the listening listening state, the port is open, waiting for the connection, but not yet connected. It's like the door of your house is open, but no one has come in yet.
look at the listening state the most important thing is to see which ports are open, these ports are which program open, close unnecessary port is to ensure the security of a very significant aspect, service ports are corresponding to a service (application), stop the service to shut down the port, For example, to turn off Port 21, simply stop the FTP service in the IIS service. Please refer to other articles for this knowledge.
If you unfortunately in the service port of the Trojan, Trojan also opened a port in the listening state.

syn-sent: Client syn_sent Status:

After the client sends a connection request, waits for a matching connection request: The
client invokes connect through the application for active open. The client TCP sends a SYN to request a connection. The state is then set to syn_sent./*the socket is actively attempting to establish a connection. Waiting for a matching connection request after sending a connection request * *

When a connection is requested the client first sends a sync signal to the machine to be accessed, at which point the state is syn_sent, and if the connection succeeds it becomes established, and Syn_sent state is very short under normal circumstances. For example, to visit the site http://www.baidu.com, if it is a normal connection, use TCPView to observe IEXPLORE. EXE (IE) will find a connection that quickly changes from syn_sent to established, indicating a successful connection. Syn_sent may not be seen in a fast state.

If you find a lot of syn_sent appear, there are generally such a number of situations, one is that you want to visit the site does not exist or the line is not good, the second is scanning a network with scan software machine, there will be a lot of syn_sent, the other is possible in the virus, such as the "Shock wave", When the virus attacks, it scans other machines, so many syn_sent appear.

syn-received: Server-side State SYN_RCVD

After receiving and sending a connection request, wait for confirmation of the connection request. When the server receives the synchronization signal sent by the client, the flag bit ACK and SYN 1 are sent to the client, at which time the server is in SYN_RCVD state and if the connection succeeds it becomes established, SYN_RCVD state is very short under normal circumstances. If you find a lot of SYN_RCVD states, your machine could be attacked by a SYN flood DOS (Denial of service) attack.

the principle of the SYN flood attack is:

In the three handshake, the attack software sends a SYN connection request (the first step of the handshake) to the attacked server, but the address is forged, such as the attack software randomly falsifying 51.133.163.104, 65.158.99.152, and so on. When the server receives the connection request, it sends the flag ACK and SYN 1 to the client (the second step of the handshake), but the IP addresses of these clients are forged and the server cannot find the client, which means the third step of the handshake is impossible to complete. In
this case the server side will generally retry (send Syn+ack to the client again) and wait for a while to discard the unfinished connection, the length of which we call the Syn Timeout, which is generally the order of magnitude of the minute (approximately 30 seconds-2 minutes); A user exception that causes one thread in the server to wait 1 minutes is not a big problem, but if a malicious attacker simulates this massively, the server will consume a lot of resources to maintain a very large semi-join list----Tens of thousands of connections, Even a simple save and traverse will consume a lot of CPU time and memory, not to mention the constant syn+ack of the IP in this list. At this point, from a normal customer's point of view, the server has lost its response, which we call: Server-side received SYN flood attack (SYN flood attack)

established: Represents an open connection.

The established state is that the two machines are transmitting data, and the most important thing to observe in this state is to see which program is in the established state.
the server appears with many established states: Netstat-nat |grep 9502 or can be detected using lsof-i:9502.
Disconnect when the client does not actively close: the fin sent by the client is missing or not sent. At
this time if the client is disconnected when the fin packet sent, then the server will be in close_wait state;
At this time if the client is disconnected when the fin packet is not sent, then the service side or display established state;
As a result, the client reconnected to the server.
and the new connection to the client (that is, just broken off the reconnect) in the server is certainly established; If the client repeats this situation, then the server will appear a large number of fake established connections and close_wait connections.
The end result is that the new client cannot connect, but with Netstat you can still see that a connection has been established and the established is displayed, but the program code is always inaccessible.

fin-wait-1: Waiting for a remote TCP connection interrupt request, or confirmation of a previous connection interrupt request

The active close end application calls Close, so its TCP sends a FIN request to shut down the connection actively and then into the fin_wait1 state./* The socket is closed, and the connection is Shutting down. Wait for a connection interrupt request from a remote TCP, or a confirmation of a previous connection interrupt request * *

fin-wait-2: Wait for connection interrupt request from remote TCP

The active close end receives an ACK, and then enters the fin-wait-2./* Connection is closed, and the socket is waiting for a shutdown from the remote ends. Waiting for connection interrupt request from remote TCP */

This is the state of the famous semi shutdown , which is the state after the client and the server shook hands two times when the connection was closed. In this state, the application also has the ability to accept data, but it has been unable to send data, but there is also a possibility that the client has been in a fin_wait_2 state and the server has been in the Wait_close state until the application layer decides to turn off the state.
close-wait: Waiting for a connection interrupt request from a local user

After the passive shutdown (passive close) TCP receives the FIN, an ACK is issued to respond to the fin request (its reception is also passed as a file terminator to the upper application) and into close_wait. /* The remote end has shut down and waiting for the socket to close. Waiting for a connection interrupt request from a local user * *
CLOSING: Waiting for remote TCP to confirm connection interruption

Relatively rare./* Both sockets are shut down but we still don ' t have all our data sent. Wait for a remote TCP to confirm the connection interruption
last-ack: Wait for confirmation that the original connection to the remote TCP interrupt request

After a passive shutdown for a period of time, the application that receives the end of the file calls the close shutdown connection. This causes its TCP to also send a FIN, waiting for the other's ACK. It's in the Last-ack. /* The remote end has shut down, and the socket is closed. Waiting for acknowledgement. Wait for confirmation that the connection interrupt request originally sent to remote TCP.
time-wait: Wait enough time to ensure that remote TCP receives a confirmation of a connection interrupt request

When the fin is received at the active shutdown, TCP sends an ACK packet and enters the time-wait state. /* The socket is waiting after closing to handle packets still the network. Wait enough time to ensure that remote TCP receives a confirmation of a connection interrupt request * *

Time_wait wait state, this state is also called 2MSL State, said that after the Time_wait2 sent the last ACK datagram, to enter the TIME_WAIT state, this state is to prevent the last handshake of the datagram is not transmitted to the other side of the prepared ( Note that this is not a four-time handshake, this is the fourth handshake of the insurance status. This state is largely a guarantee that both sides can end normally, but the problem comes.

Because of the 2MSL state of the socket (socket is the meaning of IP and port pair, socket), so that the application in 2MSL time is not able to use the same socket again, for the client program is good, but for service programs, such as httpd, it always use the same port for service, And in the 2MSL time, the boot httpd will have errors (sockets are used). To avoid this error, the server gives the concept of a quiet time, which is to say that, although the server can be restarted during the 2MSL time, the server still waits for the 2MSL time in the past for the next connection.
CLOSED: No connection Status

The passive closed end enters the closed state after receiving an ACK packet. The connection ends./* The socket is not being used. No Connection Status * *

TCP State Migration

Everyone is familiar with the netstat-a command, but you notice that the State column does not, basically shows the established,time_wait,close_wait, what exactly does this mean?
We all understand. TCP initialization connection three times shake hands: Send SYN Package, and then return Syn/ack packet, and then send an ACK package, connection is formally established. But there is a discrepancy, and when the requestor receives the Sys/ack packet, it begins to establish the connection, and the requested person does not establish the connection until the third handshake is complete. But do you understand how closing the connection works? Close the connection to four times handshake: fat fin bag, ack package, fin bag, ack package, four times handshake. Why, because the TCP connection is Full-duplex, I turn off your connection, and that doesn't mean you shut down my connection.

Client normal TCP State migration:

Closed->syn_sent->established->fin_wait_1->fin_wait_2->time_wait->closed

Server is under normal TCP state migration:

Closed->listen->syn received->established->close_wait->last_ack->closed

When the client starts to connect, the server is still in listening,
After the client sends a SYN packet, he is in the Syn_sent state, and the server is in the Sys receiving state.
Then confirm each other into the connection state established.
When the client requests to close the connection, the client sends a FIN packet, the client enters the fin_wait_1 state, waits for the other's confirmation package,
The server sends an ACK packet to the customer, the client receives the ACK packet to end fin_wait_1 state, enters the fin_wait_2 state, waits for the server to send over the shutdown request,
After the server sends a FIN package, it enters the close_wait state,
When the client receives the fin packet from the server, the Fin_wait_2 state ends, then a confirmation packet is given to the server-side fin packet, and the client then enters the time_wait,
When the server receives a confirmation package, the Close_wait status is terminated,
At this point the server side really shut down the connection. But the client is still in the TIME_WAIT state,
When will it be over? I'm here to talk about a term: 2MSL waiting state, in fact, Time_wait is the 2MSL waiting state,
Why to set this state, because there is enough time to get the ACK packet to the server side, if the server side confiscated ACK packets, timed out, and then send a fin packet, until the server received an ACK packet.
The TIME_WAIT state wait time is twice times as long as TCP restarts without connecting to any requests.
Have you found a problem: if the other party in the third handshake when the problem, such as the fin bag, do not know what reason lost the package, but this side has been in the Fin_wait_2 state, and TCP/IP does not set this state of expiration, then he will keep this state, More and more fin_wait_2 states can cause the system to crash.
The problem I encountered above is mainly because the TCP end process is not finished, resulting in the connection is not released. Now set up a client to actively disconnect, the process is as follows:

Client message Server Close () ------FIN-------> Fin_wait1 close_wait <-----ACK------- Fin_wait2 Close () <------FIN------ Time_wait Last_ack ------ACK-------> CLOSED CLOSED

The server-side connection is in a "suspend" state while the client is in the state of waiting for a response because the server's socket is not invoked when the client is closed.
A typical feature of this problem is that one end is fin_wait2 and the other end is close_wait. But the fundamental problem is that the procedure is poorly written and needs to be improved.

-------------------------------------------------------------------------
Close_wait,tcp cancer, a friend of TCP.
The reason for the generation of close_wait state
First we know that if our server program Apache is in the close_wait state, it means that the socket is closed passively.
Because if the client side takes the initiative to disconnect the current connection, then both sides will need four packet to close the TCP connection:
Client---> FIN---> Server
Client <---ACK <---Server
The client side is in the fin_wait_2 state, and the server program is in the Close_wait state.
Client <---FIN <---Server
The Server then sends the fin to client,server for the Last_ack state.
Client---> ACK---> Server
The client responds to the ACK, then the server's socket is actually placed in the closed state.
The Server program is in a close_wait state, not a last_ack state, indicating that the fin has not been sent to the client, so there may be a lot of data to send or something else to do before closing the connection, causing the fin packet to not be sent.
Usually, a close_wait will last for at least 2 hours. If a rogue specially wrote a program that caused you a bunch of close_wait and consumed your resources, it is usually not until the release of the moment that the system is resolved to collapse.
This time can only be shortened by modifying the parameters of TCP/IP: Modifying the tcp_keepalive_* series parameters helps solve this problem.
The solution to this problem is to modify the system's parameters, the system default timeout is 7,200 seconds, that is, 2 hours, this is too large, you can modify the following several parameters:

Sysctl-w net.ipv4.tcp_keepalive_time=30 Sysctl-w net.ipv4.tcp_keepalive_probes=2 Sysctl-w net.ipv4.tcp_keepalive_intvl=2

Then, execute the sysctl command to make the modification take effect.
The connection process is represented by a series of States, which are:

Listen,syn-sent,syn-received,established,fin-wait-1,fin-wait-2,close-wait,closing,last-ack,time-wait and closed

1, establish the Connection agreement (three times handshake)

(1) The client sends a TCP message with a SYN flag to the server. This is message 1 in the three handshake process.

(2) server-side response to the client, this is the three handshake in the 2nd message, this message with both ACK and SYN logo. It therefore represents a response to a client-side SYN message, while labeling SYN to the client and asking the client if it is ready for data communication.

(3) The customer must again respond to the service segment an ACK message, this is the message segment 3.

2, Connection termination protocol (four times handshake)

Because the TCP connection is Full-duplex, each direction must be closed separately. The principle is that when one party completes its data sending task, it can send a fin to terminate the connection in this direction. Receiving a fin only means that there is no data flow in this direction, and a TCP connection can still send data after receiving a fin. The side that first closes will perform the active shutdown while the other side performs the passive shutdown.

(1) The TCP client sends a FIN, which is used to turn off client to server data transfer (message segment 4).

(2) The server receives this fin, it sends back an ACK, confirming that the serial number is the received number plus 1 (message Segment 5). Like Syn, a fin will occupy an ordinal number.

(3) The server shuts down the client's connection and sends a FIN to the client (message segment 6).

(4) The customer segment sends back ACK message confirmation, and the confirmation serial number is set to receive the serial number plus 1 (message paragraph 7).

CLOSED: There's nothing to say about this, the initial state.

LISTEN: This is also very easy to understand a state, indicating that a server side of the socket is in the listening state, you can accept the connection.

SYN_RCVD: This state is accepted to the SYN packet, under normal circumstances, this state is a server-side socket in the establishment of TCP connections during the three handshake session in the process of a middle state, very short, basically with netstat you are very difficult to see this state, Unless you deliberately write a client test program, intentionally three times TCP handshake process of the last ACK message is not sent. Therefore, when the client's ACK message is received, it will enter the established state.

Syn_sent: This state echoes with SYN_RCVD, when the client socket performs connect connection, it first sends the SYN message, so it then enters the syn_sent state and waits for the 2nd message in the service side to send a handshake of three times. The Syn_sent state indicates that the client has sent a SYN message.

Established: This is easy to understand, indicating that the connection has been established.

Fin_wait_1: This state should explain well, in fact fin_wait_1