Linux tutorial: Querying the number of concurrent connections and connection status of Nginx

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

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 (number of requests waiting to be processed)

SYN_RECV 30

ESTABLISHED 1597 (normal data transmission status)

FIN_WAIT1 51

FIN_WAIT2 504

TIME_WAIT 1057 (number of requests completed and waiting for timeout to end)

Other parameter descriptions:

CLOSED: No connection is active or in progress

LISTEN: The server is waiting for an incoming call

SYN_RECV: A connection request has been made 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: Waiting for all packets to die

CLOSING: Both sides try to close at the same time

TIME_WAIT: The other side has initialized a release

LAST_ACK: Wait 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 there is an exception on the server, eighty or ninety percent of the time it will be the following two situations:

1. The server maintains a large number of TIME_WAIT state

2. The server maintains a large number of CLOSE_WAIT states. Simply put, the excessive number of CLOSE_WAIT is caused by improper handling of passively closed connections.

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 Linux tutorial: Querying the number of concurrent connections and connection status of Nginx. For more information, please follow other related articles on the PHP Chinese website!