TCP connection status analysis: sync_recv, close_wait, time_wait

Netstat-N | awk '/^ TCP/{++ s [$ NF]} end {for (a in S) print a, s [a]}'

Result:

In addition to established, we can see several statuses with many connections: fin_wait1, time_wait, close_wait, syn_recv, and last_ack;ArticleBriefly describe the conditions for generating these states, the impact on the system, and the handling method.

TCP status

Shows the TCP status:

Maybe a little dazzled? Let's take a look at this sequence chart.

Next, let's take a look at the three TCP statuses that you are generally concerned about.

Syn_recv

The server is in the syn_recv status when it receives the established SYN Packet and does not receive the ACK packet. There are two related system configurations:

1, net. ipv4.tcp _ synack_retries: integer

The default value is 5.

For the remote connection request SYN, the kernel will send SYN+Ack datagram to confirm receipt of the previous SYN connection request package. This is the second step of the so-called threeway handshake mechanism. The number of SYN + ACK sent by the kernel before the connection is abandoned. It should not be greater than 255. The default value is 5, corresponding to the left-right time of 180 seconds. We usually do not modify this value because we want TCP connections not to be established due to occasional packet loss.

2, net. ipv4.tcp _ syncookies

Net. ipv4.tcp _ syncookies = 1 is usually set on the server to prevent SYN flood attacks. Assume that a user suddenly crashes or loses connection after sending a SYN packet to the server, the server cannot receive the ACK packet from the client after sending the SYN + ACK response packet (the third handshake cannot be completed ), in this case, the server will generally retry (re-send SYN + ACK to the client) and wait for a while before discarding the unfinished connection. The length of this time is called syn timeout, generally, this time is an order of magnitude (about 30 seconds-2 minutes ).

These TCP connections in sync_recv are called semi-connections,And stored in the kernel semi-connection queueWhen the kernel receives the ACK packet sent from the peer end, it searches for the semi-connection queue, stores the compliant requst_sock information in the queue that completes the three-way handshake, and then deletes the semi-connection. A large number of TCP connections of sync_recv will cause semi-connection queue overflow, so that subsequent connection establishment requests will be directly discarded by the kernel, which is a SYN Flood attack.

One of the effective measures to prevent SYN flood attacks is SYN Cookie. SYN Cookie principle was invented by D. J. bernstain and Eric Schenk. SYN Cookie is a method used to modify the three-way handshake protocol on the TCP server to prevent SYN flood attacks. The principle is that when the TCP server receives the tcp syn Packet and returns the tcp syn + ACK packet, a cookie value is calculated based on the SYN Packet instead of a dedicated data zone. When receiving a tcp ack packet, the TCP server checks the validity of the tcp ack packet based on the cookie value. If valid, assign a dedicated data area to process future TCP connections.

The number of syn_recv connections in the observation service is 7314. This number is normal for a high-concurrency communication server.

Close_wait

The client that initiates the TCP connection to close the connection, and the server that passively closes the connection. The TCP status of the server that passively closes the fin but does not issue Ack is close_wait. This is generally because the server sideCodeIf there are a lot of close_wait problems on your server, you should consider checking the code.

Time_wait

Three-way handshake disconnection rules defined by the TCP protocol , The socket that initiates the active socket shutdown will enter the time_wait status. Time_wait status will last for 2 MSL (max segment lifetime) , In Windows, the default value is 4 minutes, that is, 240 seconds. The socket in time_wait status cannot be recycled. . The specific phenomenon is for a server that handles a large number of transient connections , If the server closes the client connection, the server may have a large number of sockets in the time_wait status, or even more than the number of sockets in the established status. , It seriously affects the server's processing capabilities, even consumes available sockets, and stops the service.

Why do we need time_wait? Time_wait is a mechanism used by the TCP protocol to ensure that the re-allocated socket is not affected by the residual delayed resend packets.,Is a logical guarantee.

There are generally three system parameters related to time_wait status. The factory settings are as follows:

Net. ipv4.tcp _ tw_recycle = 1

Net. ipv4.tcp _ tw_reuse = 1

Net. ipv4.tcp _ fin_timeout = 30

Net. ipv4.tcp _ fin_timeout. The default value is 60 s, which reduces fin_timeout and time_wait connections.

Net. ipv4.tcp _ tw_reuse = 1 indicates enabling reuse. Allow time-Wait sockets to be re-used for a New TCP connection. The default value is 0, indicating that the TCP connection is disabled;

Net. ipv4.tcp _ tw_recycle = 1 indicates to enable quick recovery of Time-Wait sockets in TCP connections. The default value is 0, indicating to disable it.

Original

Http://maoyidao.iteye.com/blog/1744277