Shulou(Shulou.com)06/01 Report--

This article to share with you is about how to parse LINUX netstat connection state and TCP state transition, Xiaobian think quite practical, so share to everyone to learn, I hope you can read this article after harvest, not much to say, follow Xiaobian to see it.

LINUX netstat connection state analysis and TCP state transition

Level is limited. Please indicate if there is any error.

We often see an entry for port connection status in netstat -anlp

gaopeng@bogon:~$ netstat -anlp|grep 10050

(Not all processes could be identified, non-owned process info

will not be shown, you would have to be root to see it all.)

tcp 0 0 0.0.0.0:10050 0.0.0.0:* LISTEN 2502/server

tcp 0 0 192.168.190.81:48008 192.168.190.81:10050 ESTABLISHED 2510/client

tcp 0 0 192.168.190.81:10050 192.168.190.81:48008 ESTABLISHED 2502/server

or take another example

gaopeng@bogon:~$ netstat -anlp|grep 10050

(Not all processes could be identified, non-owned process info

will not be shown, you would have to be root to see it all.)

tcp 1 0 192.168.190.81:48008 192.168.190.81:10050 CLOSE_WAIT 2510/client

tcp 0 0 192.168.190.81:10050 192.168.190.81:48008 FIN_WAIT2 -

For example, LISTEN, ESTABLISHED, CLOSE_WAIT, FIN_WAIT2, what do these really mean?

Here is a TCP state transition diagram (a very important one):

The solid line in the figure is the active side, the dotted line is the passive side, such as SERVER-CLIENT terminal,CLIENT terminal requests to disconnect, then he is the active side.

The following is a description of various states (excerpted from Xing Wenpeng LINUX system programming handout)

CLOSED: There is nothing to say about this, indicating the initial state.

LISTEN: This is also a very easy to understand state, indicating that a SOCKET on the server side is in a listening state and can accept connections.

SYN_RCVD: This state indicates that SYN packets have been received. Under normal circumstances, this state is the third time SOCKET on the server side establishes TCP connections.

An intermediate state in the handshake session, very short, basically netstat You are hard to see this state unless you specifically write a customer

The terminal test program deliberately does not send the last ACK message in the three-time TCP handshake process. Therefore, in this state, when receiving the ACK message from the client,

After that, it will enter the ESTABLISHED state.

SYN_SENT: This state echoes SYN_RCVD, and when client SOCKET performs a CONNECT connection, it sends SYN first, and therefore immediately

It enters the SYN_SENT state and waits for the server to send the second message in the three-way handshake. The SYN_SENT state indicates that the client has sent SYN

Message.

ESTABLISHED: This is easy to understand, indicating that the connection has been established.

FIN_WAIT_1: This state needs to be explained. In fact, the real meaning of FIN_WAIT_1 and FIN_WAIT_2 states is to wait for the FIN report of the other party.

Wen. The difference between these two states is that the FIN_WAIT_1 state is actually when SOCKET is in ESTABLISHED state, it wants to actively close the connection, and the

When the other party sends FIN message, the SOCKET enters FIN_WAIT_1 state. When the other party responds to the ACK message, it enters the FIN_WAIT_2 state.

Of course, under actual normal circumstances, no matter what the other party is under, it should immediately respond to the ACK message, so the FIN_WAIT_1 state is generally a comparison.

The FIN_WAIT_2 state is sometimes visible with netstat.

FIN_WAIT_2: This state has been explained in detail above. In fact, SOCKET in FIN_WAIT_2 state indicates semi-connection, i.e., one party requires

Close the connection, but also tell the other party that I still have some data to send to you for the time being, and then close the connection later.

TIME_WAIT: Indicates that the FIN message from the other party has been received and an ACK message has been sent. After waiting for 2MSL, the CLOSED available state can be returned. if

In the FIN_WAIT_1 state, when receiving the message with FIN flag and ACK flag from the other party, you can directly enter the TIME_WAIT state without passing through

FIN_WAIT_2 status.

CLOSING: This state is quite special. In actual circumstances, it should be rare and belongs to a relatively rare exception state. Normally, when you send

After FIN message, it is reasonable to receive ACK message from the other party first (or receive it at the same time), and then receive FIN message from the other party. But CLOSING the state table

After sending FIN messages, you did not receive ACK messages from the other party, but also received FIN messages from the other party. Under what circumstances would this happen?

And? In fact, if you think about it, it is not difficult to conclude that if both parties close a SOCKET almost at the same time, then both parties appear at the same time.

When FIN messages are sent, the CLOSING state appears, indicating that both parties are closing the SOCKET connection.

wrote a socket simple server and client Mini programs do nothing, just to test the connection status, bind port 10050, the test is done on a machine 190.81

Bind NIC for all NIC of this machine INADDR_ANY macro

Let's analyze it now.

1. Normal connection

gaopeng@bogon:~$ netstat -anlp|grep 10050

(Not all processes could be identified, non-owned process info

will not be shown, you would have to be root to see it all.)

tcp 0 0 0.0.0.0:10050 0.0.0.0:* LISTEN 2502/server

tcp 0 0 192.168.190.81:48008 192.168.190.81:10050 ESTABLISHED 2510/client

tcp 0 0 192.168.190.81:10050 192.168.190.81:48008 ESTABLISHED 2502/server

2. Default disposal mode of ctrl+c SIGN signal on server

gaopeng@bogon:~$ netstat -anlp|grep 10050

(Not all processes could be identified, non-owned process info

will not be shown, you would have to be root to see it all.)

tcp 1 0 192.168.190.81:48008 192.168.190.81:10050 CLOSE_WAIT 2510/client

tcp 0 0 192.168.190.81:10050 192.168.190.81:48008 FIN_WAIT2 -

Server ctrl+c SIGN signal default disposal mode

Active server

passive client

Obviously at this point the active party sends a FIN message to the passive party requesting closure of the connection,

The passive party receives a FIN message and returns an ACK message to the passive party. At the same time, the passive party sends a FIN message to the active party requesting to close the connection. However, the active party

Since SIGINT has already entered the city and terminated, the FIN message cannot be received. Therefore, at this time, the SERVER connection of the active party is in FIN_WAIT2 state.

The FIN message from the passive side cannot be received, and the CLIENT side of the passive side is in CLOSE_WAIT state because the server side cannot accept the FIN message.

3、

gaopeng@bogon:~$ netstat -anlp|grep 10050

(Not all processes could be identified, non-owned process info

will not be shown, you would have to be root to see it all.)

tcp 0 0 0.0.0.0:10050 0.0.0.0:* LISTEN 2568/server

tcp 1 0 192.168.190.81:10050 192.168.190.81:48010 CLOSE_WAIT 2568/server

tcp 0 0 192.168.190.81:48010 192.168.190.81:10050 FIN_WAIT2 -

Client ctrl+c SIGN signal default handling mode

passive server

Active client

This situation, contrary to the above, is not described.

Here are screenshots of the Connect 3-way handshake and Disconnect 4-way handshake:

The above is how to parse LINUX netstat connection state and TCP state transition, Xiaobian believes that some knowledge points may be seen or used in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.