The solution of TCP connection state and time_wait too much

TCP establishes three handshake processes for connections, and four handshake processes for closing connections.

TCP establishes three handshake processes for connections, and four handshake processes for closing connections.

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

(2) server-side response to the client, this is the 2nd message in the three handshake, the message with both an ACK flag and a SYN flag. So it represents the response to the client's SYN message, and it also flags the SYN to the client and asks the client if it is ready for data communication.

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

2. Connection termination protocol (four handshake)
Because TCP connections are full-duplex, each direction must be closed separately. The principle is that when a party completes its data sending task, it can send a fin to terminate the connection in this direction. Receiving a fin only means there is no data flow in this direction, and a TCP connection can still send data after receiving a fin. The first party to close will perform an active shutdown, while the other side performs a passive shutdown.

(1) The TCP client sends a fin to shut down the client-to-server data transfer (message segment 4).
(2) The server receives this fin, it sends back an ACK, confirms that the serial number is the received sequence number plus 1 (message Segment 5). As with Syn, a fin will occupy a sequence number.
(3) The server shuts down the client 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 segment 7).

CLOSED: This is nothing to say, it means the initial state.

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

SYN_RCVD: This status means that the SYN message is received, under normal circumstances, this state is the server side of the socket in the establishment of a TCP connection during the three handshake session process of an intermediate state, very short, basically with netstat you are very difficult to see this state, Unless you specifically write a client-side test program, deliberately not send the last ACK message during the three TCP handshake. Therefore, when the ACK message is received from the client, it goes into the established state.

Syn_sent: This state is echoed with the syn_rcvd thinking back, when the client socket performs a connect connection, it sends the SYN message first, so it then enters the syn_sent state and waits for the server to send the 2nd message in the three-time handshake. The Syn_sent status 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 be well explained, in fact, the real meaning of fin_wait_1 and fin_wait_2 state is to wait for each other's fin message. The difference between the two states is: The fin_wait_1 state is actually when the socket in the established state, it would like to actively close the connection, send a FIN message to the other side, when the socket is entered into the fin_wait_1 state. And when the other party responds to the ACK message, then into the fin_wait_2 state, of course, under the actual normal circumstances, regardless of the circumstances of each other, should immediately respond to the ACK message, so fin_wait_1 state is generally more difficult to see, and Fin_wait_ 2 states can also sometimes be seen with netstat.

Fin_wait_2: Above has explained in detail this state, actually fin_wait_2 the socket in the state, indicates the half connection, also namely has the party request close connection, but also tells the other side, I temporarily also some data need to transmit to you, later closes the connection again.

Time_wait: Said to receive the other side of the fin message, and sent out an ACK message, just wait for 2MSL to return to the closed usable state. If the fin_wait_1 state, received the other side with the FIN flag and the ACK flag message, you can directly into the time_wait state, without having to go through the fin_wait_2 state.

Note: MSL (maximum segment lifetime) indicates the maximum lifetime of a TCP message over the Internet, and each specific TCP implementation must select a certain MSL value. RFC 1122 recommends 2 minutes, but BSD legacy implementations take 30 seconds. time_wait The state maximum hold time is 2 * MSL, which is 1-4 minutes.

CLOSING: This kind of state is special, the actual situation should be very rare, belong to a relatively rare exception state. Normally, when you send a fin message, it is supposed to receive (or receive) the other's ACK message before receiving the other's fin message. But closing status indicates that you send fin message, and did not receive the other's ACK message, but also received the other side of the fin message. Under what circumstances will this happen? In fact, it is not difficult to come to a conclusion: that is, if the two sides close a socket at the same time, then there is a situation where both sides send the fin message, there will be a closing state, indicating that both sides are shutting down the socket connection.

Close_wait: The meaning of this state is actually expressed in waiting to be closed. How do you understand it? When the other side close a socket to send fin message to yourself, you will undoubtedly respond to an ACK message to each other, then enter into the close_wait state. Next, the real thing you really need to consider is whether you still have the data sent to the other person, if not, then you can close the socket, send fin messages to each other, that is, close the connection. So what you need to accomplish in the close_wait state is waiting for you to close the connection.

Last_ack: This state is still relatively easy to understand, it is the passive close side after sending fin messages, and finally wait for each other's ACK message. When an ACK message is received, it is also possible to enter the closed available state.

Finally there are 2 questions answered, my own analysis of the conclusion (not necessarily guaranteed 100% correct)

1, why to establish a connection agreement is three handshake, and close the connection is four handshake it?

This is because the socket in the listen state of the server is sent in a message after it receives a request for the connection of the SYN message, and it can put the ACK and SYN (ACK response, and SYN synchronous). However, when the connection is closed, when receiving the other's fin message notification, it simply means that no data is sent to you, but not all of your data are sent to the other side, so you may not immediately close the socket, that is, you may also need to send some data to the other side, Send the FIN message to the other side to show that you agree that you can now close the connection, so it is here that the ACK message and fin messages are sent separately in most cases.

2, why time_wait state also need to wait 2MSL to return to closed status?

This is because: although both sides agree to close the connection, and the handshake of the 4 messages are also coordinated and sent, can be directly back to the closed state (like from the Syn_send state to establish state); but because we have to assume that the network is unreliable, You cannot guarantee that the last ACK message you send will be received by the other side, so the other side in the Last_ack state of the socket may be due to the timeout did not receive an ACK message, and the re-send fin message, so this time_wait state function is used to resend the possible missing ACK message, And be assured of this.

To view the number of all connection states under the current system:

[[Email protected] ~] #netstat-n|awk '/^tcp/{++s[$NF]}end{for (key in S) print Key,s[key]} '
Time_wait 286
Fin_wait1 5
Fin_wait2 6
Established 269
SYN_RECV 5
CLOSING 1

If you find that the system has a large number of time_wait state connections, by adjusting the kernel parameters to resolve:
Edit the file/etc/sysctl.conf and add the following:

Net.ipv4.tcp_syncookies = 1
Net.ipv4.tcp_tw_reuse = 1
Net.ipv4.tcp_tw_recycle = 1
Net.ipv4.tcp_fin_timeout = 30

Then execute/sbin/sysctl-p to let the parameters take effect.

Net.ipv4.tcp_syncookies = 1 means that Syn Cookies are turned on. When there is a SYN wait queue overflow, cookies are enabled to protect against a small number of SYN attacks, the default is 0, which means close;
Net.ipv4.tcp_tw_reuse = 1 means turn on reuse. Allows time-wait sockets to be re-used for new TCP connections, which defaults to 0, which means shutdown;
Net.ipv4.tcp_tw_recycle = 1 means a fast recycle of time-wait sockets in the TCP connection is turned on, and the default is 0, which means shutdown.
Net.ipv4.tcp_fin_timeout Modify the default timeout time

Additional parameter Description:
Net.ipv4.tcp_syncookies = 1 means that Syn Cookies are turned on. When there is a SYN wait queue overflow, cookies are enabled to protect against a small number of SYN attacks, the default is 0, which means close;
Net.ipv4.tcp_tw_reuse = 1 means turn on reuse. Allows time-wait sockets to be re-used for new TCP connections, which defaults to 0, which means shutdown;
Net.ipv4.tcp_tw_recycle = 1 means a fast recycle of time-wait sockets in the TCP connection is turned on, and the default is 0, which means shutdown.
Net.ipv4.tcp_fin_timeout = 30 means that if the socket is closed by the local side, this parameter determines how long it remains in the fin-wait-2 state.
Net.ipv4.tcp_keepalive_time = 1200 indicates the frequency at which TCP sends keepalive messages when KeepAlive is employed. The default is 2 hours, which is changed to 20 minutes.
Net.ipv4.ip_local_port_range = 1024 65000 indicates the range of ports used for an outward connection. Small by default: 32768 to 61000, 1024 to 65000.
Net.ipv4.tcp_max_syn_backlog = 8192 Indicates the length of the SYN queue, the default is 1024, and the queue length is 8192, which can accommodate more network connections waiting to be connected.
Net.ipv4.tcp_max_tw_buckets = 5000 indicates that the system maintains the maximum number of time_wait sockets at the same time, and if this number is exceeded, the time_wait socket is immediately cleared and a warning message is printed.
The default is 180000, which changes to 5000. For Apache, Nginx and other servers, the parameters of the last few lines can be a good way to reduce the number of time_wait sockets, but for squid, the effect is not small. This parameter controls the maximum number of time_wait sockets, preventing squid servers from being dragged to death by a large number of time_wait sockets.

Note:
Net.ipv4.tcp_tw_reuse = 1
Net.ipv4.tcp_tw_recycle = 1

Set both parameters: reuse indicates whether to allow the time-wait state of the socket to be re-applied to the new TCP connection; Recyse is to accelerate time-wait sockets recycle

This article is from the "Dream to Reality" blog, please be sure to keep this source http://lookingdream.blog.51cto.com/5177800/1792191

The solution of TCP connection state and time_wait too much