View network status with Netstat

--use Netstat to view the network status

-----------------------------2014/06/11

One, the Linux server 11 kinds of network connection status:

Figure: State machine for TCP

Normally: a normal TCP connection, there will be three stages: 1, TCP three handshake, 2, data transmission, 3, TCP four wave

Note: The following instructions are best to be understood in conjunction with "Graph: TCP state machine".

SYN: (Synchronous sequence number, Synchronize Sequence Numbers) This flag is valid only if the three-time handshake establishes a TCP connection. Represents a new TCP connection request.

ACK: (acknowledgement number) is a confirmation flag for the TCP request and indicates that the peer system has successfully received all the data.

FIN: (end sign, finish) used to end a TCP reply. However, the corresponding port is still open and ready to receive subsequent data.

1), LISTEN: First, the server needs to open a socket for monitoring, the status of LISTEN. /* The socket is listening for incoming connections. Listening for connection requests from remote TCP ports */
2), Syn_sent: The client calls connect through the application to make active open. The client TCP sends a SYN to request a connection. The state is then set to Syn_sent. /*the socket is actively attempting to establish a connection. Wait for a matching connection request after sending a connection request */

3), SYN_RECV: The server should issue an ACK to confirm the client's SYN, and send itself to the client a syn. The status is then set to SYN_RECV/* A connection request has been received from the network. Wait for confirmation of the connection request after receiving and sending a connection request */

4), established: represents an open connection, both can be made or have interacted with the data. /* The socket has an established connection. Represents an open connection, data can be sent to the user */

5), Fin_wait1: Active shutdown (active close) end application calls Close, and its TCP sends a FIN request to actively close the connection before entering the FIN_WAIT1 state./* The socket is closed, and the Connection is shutting down. Pending connection interruption request for remote TCP, or confirmation of a previous connection interruption request */

6), close_wait: Passive shutdown (passive close) After TCP receives FIN, an ACK is issued in response to the FIN request (its receive is also passed as a file terminator to the upper-level application) and enters the close_wait. /* The remote end has a shut down and waiting for the socket to close. Waiting for a connection interrupt request from a local user */

7), Fin_wait2: Active shut-off end received ACK, entered the fin-wait-2./* Connection is closed, and the socket was waiting for a shutdown from the remote End. Waiting for connection interrupt request from remote TCP */

8), Last_ack: After a period of passive shutdown, the application that receives the file terminator will call close to close the connection. This causes its TCP to also send a FIN, waiting for the other person's ACK. It went into the last-ack. /* The remote end has a shut down, and the socket is closed. Waiting for acknowledgement. Wait for the acknowledgement of the connection interrupt request that was originally sent to remote TCP */

9), Time_wait: After the active shut-off side receives the fin, TCP sends the ACK packet, and enters the time-wait state. /* The socket is waiting after close to handle packets still in the network. Wait enough time to make sure that the remote TCP receives a connection interrupt request confirmation */

10), CLOSING: relatively rare./* Both sockets is shut down but we still don ' t has all of our data sent. Wait for the remote TCP acknowledgement of the connection interruption */

11), CLOSED: Passive closed end after receiving the ACK packet, it entered the state of CLOSED. The connection ends./* The socket is not being used. No connection Status */
The formation of the TIME_WAIT state occurs only on the side of the active shutdown connection.
When the active shut-off party receives the fin request of the passive shut-off party, it sends a successful ACK to the other side, changes its state from Fin_wait2 to time_wait, and must wait twice times more MSL (Maximum Segment Lifetime, The MSL is the time that a datagram can exist in internetwork) before both sides can change the status to closed to close the connection. The current time in Rhel is 60 seconds to maintain time_wait status.

Of course, many of the above TCP states in the system have a corresponding explanation or settings, visible man TCP

Ii. about long connections and short connections:
Popular point: A short connection is the result of a TCP request, the connection ends immediately. The long connection does not break immediately, but remains until long connection timeout (the specific program has the relevant parameter description). Long connections Avoid constant TCP three-time handshake and four waves.
Long connections (keepalive) need to be maintained by both sides of the constant sending of probe packets, the KeepAlive TCP connection state between the server and the client is established. Currently the HTTP 1.1 version is the default of KeepAlive ( The 1.0 version is not keepalive by default, and IE6/7/8 and Firefox default to the HTTP 1.1 version (how to see which version of the current browser is used, which is not discussed here). Apache,java

Whether an application should use a short or long connection depends on the situation. A general application should use a long connection.

1. Linux related keepalive parameters

A, Tcp_keepalive_time–integer
How often TCP sends out keepalive messages if KeepAlive is enabled.
Default:2hours.
B, Tcp_keepalive_probes–integer
How many keepalive probes TCP sends off, until it decides that the
Connection is broken. Default Value:9.
C, Tcp_keepalive_intvl–integer
How frequently the probes is send out. multiplied by
Tcp_keepalive_probes It is time-to-kill not responding connection,
After probes started. Default value:75sec i.e. connection
Would be aborted after minutes of retries.