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

1. View the number of concurrent requests for 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]} ' return results are generally as follows:
Last_ack 5 (number of requests waiting to be processed)
SYN_RECV 30
Established 1597 (normal data transfer status)
Fin_wait1 51
Fin_wait2 504
Time_wait 1057 (number of requests processed, waiting for timeout to end)
Additional parameter Description:
CLOSED: No connection is active or in progress

LISTEN: The server is waiting to enter the call
SYN_RECV: A connection request has arrived, waiting for confirmation
Syn_sent: Application has started, open a connection
Established: Normal data transfer status
FIN_WAIT1: Application says it's done
Fin_wait2: The other side has agreed to release
Itmed_wait: Waiting for all packets to die
CLOSING: Both sides try to close simultaneously
Time_wait: The other side has initialized a release
Last_ack: Waiting for all packets to die

The three commonly used states are: Established is communicating, time_wait indicates active shutdown, close_wait indicates passive shutdown.
The TCP protocol stipulates that for a connection that has already been established, the network will have to perform four handshakes to successfully disconnect, and if one of these steps is missing, the connection is suspended and the resource occupied by the connection itself is not freed. Network server program to manage a large number of connections at the same time, it is necessary to ensure that useless connections are completely disconnected, or a large number of dead connections will waste many server resources. Of the many TCP states, the most notable states are two: Close_wait and time_wait.
Time_wait
Time_wait is formed when the link is actively closed, waiting for 2MSL time, about 4 minutes. The primary is to prevent the last ACK from being lost. Because the time_wait time can be very long, the server side should minimize the active shutdown connection
Close_wait
Close_wait is a passive shut-off connection is formed. Depending on the TCP state machine, the server side receives the fin sent by the client, then sends an ACK according to the TCP implementation, thus entering the close_wait state. However, if the server side does not perform close () and cannot be migrated from close_wait to Last_ack, there will be many close_wait state connections in the system. At this point, it may be that the system is busy processing read and write operations, and does not have a connection to the fin already received, close. At this point, Recv/read has received a connection socket for fin and will return 0.
Why do I need time_wait status?
Assuming that the final ACK is lost, the server will resend Fin,client must maintain TCP state information so that the final ACK can be re-sent, or the RST will be sent, resulting in the server thinking an error has occurred. The TCP implementation must reliably terminate the two-direction (full-duplex shutdown) of the connection, and the client must enter the TIME_WAIT state because the client may face a situation where the final ACK is re-issued.
Why does the time_wait state need to remain 2MSL for such a long time?
If the TIME_WAIT state hold time is not long enough (for example, less than 2MSL), the first connection terminates normally. A second connection with the same related five-tuple appears, and the first concatenated duplicate message arrives, interfering with the second connection. The TCP implementation must prevent a duplicate message of a connection from appearing after the connection is terminated, so that the time_wait state is kept long enough (2MSL), and the TCP message in the corresponding direction is either completely unresponsive or discarded. When a second connection is established, it is not confused.
Time_wait and close_wait status socket too many
If the server is out of the ordinary, 80% or 90% is the following two scenarios:
1. The server maintains a large number of time_wait states
2. The server maintains a large number of close_wait states, simply speaking, the number of close_wait is too large due to passive shutdown connection improper processing.

Since Linux is assigned to a user's file handle is limited, and time_wait and close_wait two states if it has been maintained, it means that the corresponding number of channels have been occupied, and is "Occupy Manger not Hard", once the maximum number of handles, the new request can not be processed , followed by a large number of too many Open files exception, Tomcat crashes.

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