Detailed introduction on how to check the number of concurrent connections and connection status of Nginx under Linux

Linux Check the number of concurrent connections and connection status of Nginx, etc.

1. Check the number of concurrent requests of the Web server (Nginx Apache) and its TCP connection status:

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

Or:

netstat -n | awk '/ ^tcp/ {++state[$NF]} END {for(key in state) print key,"t",state[key]}'The return result is generally as follows:

LAST_ACK 5 （正在等待处理的请求数）
SYN_RECV 30 
ESTABLISHED 1597 （正常数据传输状态） 
FIN_WAIT1 51 
FIN_WAIT2 504 
TIME_WAIT 1057 （处理完毕，等待超时结束的请求数）

Other parameter descriptions:

CLOSED: No connection is active or in progress

LISTEN: The server is waiting for incoming calls

SYN_RECV: A The connection request has arrived, waiting for confirmation

SYN_SENT: The application has started, opening a connection

ESTABLISHED: Normal data transfer status

FIN_WAIT1: The application says it has completed

FIN_WAIT2: The other side has agreed to release

ITMED_WAIT: Wait for all groups to die

CLOSING: Both sides try to close at the same time

TIME_WAIT: Another A release has been initialized on one side

LAST_ACK: Waiting for all packets to die

The three commonly used states are: ESTABLISHED means communicating, TIME_WAIT means active closing, and CLOSE_WAIT means passive closing.

The TCP protocol stipulates that for an established connection, both parties on the network must perform four handshakes to successfully disconnect. If one of these steps is missing, the connection will be in a state of suspended animation and the resources occupied by the connection itself will will not be released. The network server program must manage a large number of connections at the same time, so it is necessary to ensure that useless connections are completely disconnected, otherwise a large number of dead connections will waste a lot of server resources. Among the many TCP states, there are two most noteworthy states: CLOSE_WAIT and TIME_WAIT.

TIME_WAIT

TIME_WAIT is formed when the link is actively closed, waiting for 2MSL time, about 4 minutes. Mainly to prevent the last ACK from being lost. Since TIME_WAIT will take a very long time, the server should try to minimize the number of active connections closed

CLOSE_WAIT

CLOSE_WAIT is formed by passively closing connections. According to the TCP state machine, when the server receives the FIN sent by the client, it sends ACK according to the TCP implementation, so it enters the CLOSE_WAIT state. However, if the server does not execute close(), it cannot migrate from CLOSE_WAIT to LAST_ACK, and there will be many connections in the CLOSE_WAIT state in the system. At this time, it may be that the system is busy processing read and write operations and has not closed the connection that has received FIN. At this time, recv/read has received the FIN connection socket and will return 0.

Why do we need TIME_WAIT state?

Assuming that the final ACK is lost, the server will resend the FIN. The client must maintain TCP status information so that the final ACK can be resent. Otherwise, RST will be sent, resulting in the server thinking that an error has occurred. TCP implementations must reliably terminate both directions of the connection (full duplex closed), and the client must enter the TIME_WAIT state because the client may be faced with retransmitting the final ACK.

Why does the TIME_WAIT state need to remain 2MSL for such a long time?

If the TIME_WAIT state is not maintained long enough (for example, less than 2MSL), the first connection will be terminated normally. A second connection appears with the same associated quintuple, and duplicate packets from the first connection arrive, interfering with the second connection. The TCP implementation must prevent duplicate messages from a certain connection from appearing after the connection is terminated, so keep the TIME_WAIT state long enough (2MSL), and the TCP messages in the corresponding direction of the connection will either be completely responded to or discarded. There is no confusion when establishing a second connection.

Too many sockets in TIME_WAIT and CLOSE_WAIT status

If the server is abnormal, 80% to 90% of the time it will be the following two situations:

1. The server maintains a large number of TIME_WAIT status

2. The server maintains a large number of CLOSE_WAIT status. Simply put, the excessive number of CLOSE_WAIT is caused by improper passive closingconnection processing.

Because the file handle allocated to a user by Linux is limited, and if the two states of TIME_WAIT and CLOSE_WAIT are always maintained, it means that the corresponding number of channels are always occupied, and they are "occupying the pit" No effort", once the upper limit of the number of handles is reached, new requests cannot be processed, followed by a large number of Too Many Open Files exceptions, and Tomcat crashes.

The above is the detailed content of Detailed introduction on how to check the number of concurrent connections and connection status of Nginx under Linux. For more information, please follow other related articles on the PHP Chinese website!