TCP connection status explanation and troubleshooting (1)

TCP connection status explanation and troubleshooting (1)

By understanding the status of TCP, We Can troubleshoot and locate network or system faults.

I. TCP status

LISTENING: listens for connection requests from remote TCP ports.

First, the server needs to open a socket for listening, and the status is LISTEN.

A service is provided in the LISTENING status. a tcp status change is the status change of a port. When a service is provided, a port is opened. For example, the www service is enabled on port 80 by default, the default port for providing the ftp service is 21. When the provided service is not connected, it is in the LISTENING status. After the FTP service is started, it is in the LISTENING status. When the listener is in the LISTENING status, the port is open, waiting for connection, but not yet connected. Just as the door of your house has been opened, but no one has come in.

To check the LISTENING status, the most important thing is to check which ports are enabled on the local machine and which program these ports are enabled. Closing unnecessary ports is a very important aspect to ensure security, the Service port corresponds to a service (Application). If you stop the service, the port is closed. For example, to disable port 21, you only need to stop the FTP service in the IIS service. For more information, see other articles.

If you are unfortunately in the service Port Trojan, the trojan also opens a port in the LISTENING status.

● SYN-SENT: client SYN_SENT status:

After sending the connection request again, wait for the matching connection request:

The client uses the application to call connect for active open. therefore, the client tcp sends a SYN request to establish a connection. then the status is set to SYN_SENT. /* The socket is actively attempting to establish a connection. wait for the matched connection request after sending the Connection Request */

When a request is sent to a connection, the client first sends a synchronous signal to the machine to be accessed. The status is SYN_SENT. If the connection is successful, the status changes to ESTABLISHED. Under normal circumstances, the SYN_SENT status is very short. For example, to access the website http://www.baidu.com, if it is a normal connection, use TCPView to observe the connection ESTABLISHED by IEXPLORE. EXE (IE) will find that soon from SYN_SENT to ESTABLISHED, indicating the connection is successful. SYN_SENT may not be in a fast state.

If many SYN_SENT instances are found, there are usually several situations: first, the website you want to visit does not exist or the line is not good, and second, scanning a machine with a network segment using Scan software, there will also be many SYN_SENT, and the virus may be involved. For example, if the "Shock Wave" is in progress, other machines will be scanned during the virus attack, so many SYN_SENT will appear.

● SYN-RECEIVED: Server state SYN_RCVD

After receiving and sending a connection request, wait for the other party to confirm the connection request.

When the server receives the synchronous signal sent by the client, it marks the ACK and

SYN 1 is sent to the client, and the server is in the SYN_RCVD State. If the connection is successful, it becomes ESTABLISHED. Under normal circumstances, the SYN_RCVD state is very short.

If many SYN_RCVD states are found, your machine may be attacked by SYN Flood DoS attacks.

● SYN Flood attack principle:

During the three-way handshake, the attack software sends a SYN connection request to the attacked server (the first step of the handshake), but the address is forged, for example, the attack software randomly spoofs addresses such as 51.133.163.104 and 65.158.99.152. When the server receives the connection request, it sends the flag ACK and SYN to the client (step 2 of handshake). However, the IP addresses of these clients are forged and the server cannot find the client, that is to say, the third step of the handshake cannot be completed.

In this case, the server will generally retry (re-send SYN + ACK to the client) and wait for a while before discarding the unfinished connection. The length of this time is called SYN Timeout, generally, this time is an order of magnitude of minutes (about 30 seconds-2 minutes). A user exception causes a server thread to wait for 1 minute, which is not a big problem, however, if a malicious attacker simulates this situation in large numbers, the server will consume a lot of resources to maintain a very large semi-connection list-tens of thousands of semi-connections, even simply saving and traversing will consume a lot of CPU time and memory, not to mention constantly retrying the IP addresses in this list with SYN + ACK. In this case, from the perspective of normal customers, the server has no response. In this case, we call it a SYN Flood attack (SYN Flood attack) on the server)

● ESTABLISHED: indicates an open connection.

The state of ESTABLISHED indicates that the two machines are transmitting data. The most important thing to observe is to see which program is in the state of ESTABLISHED.

The server has many ESTABLISHED statuses: netstat-nat | grep 9502 or lsof-I: 9502.

When the client is not actively closed, the connection is closed: the FIN sent by the client is lost or not sent.

At this time, if the FIN package is sent when the client is disconnected, the server will be in the CLOSE_WAIT status;

At this time, if the FIN package is not sent when the client is disconnected, the server will still display the ESTABLISHED status;

Result The client reconnects to the server.

The newly connected client (that is, the disconnected client is re-connected) must be ESTABLISHED on the server. If the client repeats this situation, then, the server will have a lot of fake ESTABLISHED connections and CLOSE_WAIT connections.

The final result is that other new clients cannot be connected. However, with netstat, you can still see that a connection has been ESTABLISHED and ESTABLISHED is displayed, but you cannot enter the program code.

● FIN-WAIT-1: waiting for confirmation of remote TCP connection interruption requests or previous connection interruption requests

The application on the active close side calls close, so TCP sends a FIN request to close the connection and enters the FIN_WAIT1 state. /* The socket is closed, and the connection is shutting down. wait for the confirmation of the remote TCP connection interruption request or the previous connection interruption request */

● FIN-WAIT-2: waits for connection interruption requests from remote TCP

After receiving the ACK, the client enters FIN-WAIT-2. /* Connection is closed, and the socket is waiting for a shutdown from the remote end. wait for connection interruption requests from remote TCP */

This is the famous semi-closed status, which is the status after the client and server shake hands twice when the connection is closed. In this state, the application can accept data, but data cannot be sent. However, the client is always in the FIN_WAIT_2 state, and the server is always in the WAIT_CLOSE state, the Application Layer determines to close this state.

● CLOSE-WAIT: Waiting for connection interruption requests from Local Users

Passive close (passive close) after TCP receives the FIN, it sends an ACK to respond to the FIN request (its receipt is also passed to the upper-layer application as the file Terminator) and enters CLOSE_WAIT. /* The remote end has shut down, waiting for the socket to close. waiting for a connection interruption request from a local user */

● CLOSING: waiting for confirmation of remote TCP connection interruption

Rare./* Both sockets are shut down but we still don't have all our data sent. Wait for remote TCP to confirm the connection interruption */

● LAST-ACK: waiting for confirmation of the original connection interruption request sent to remote TCP

After a period of time, the application that receives the file Terminator will call CLOSE to CLOSE the connection. As a result, TCP also sends a FIN, waiting for the ACK of the other party. the LAST-ACK. /* The remote end has shut down, and the socket is closed. waiting for acknowledgement. wait for confirmation of the original connection interruption request sent to remote TCP */

● TIME-WAIT: WAIT for enough TIME to ensure that the remote TCP receives the confirmation of the connection interruption request.

After the active shutdown side receives the FIN, TCP sends the ACK packet and enters the TIME-WAIT Status. /* The socket is waiting after close to handle packets still in the network. Wait for enough time to ensure that The remote TCP receives the confirmation of The connection interruption request */

TIME_WAIT wait state, which is also called 2MSL state. It indicates that the TIME_WAIT state is entered after TIME_WAIT2 sends the last ACK datagram, this status prevents the datagram of the last handshake from being transmitted to the other party and prepared (note that this is not the four handshakes, but the fourth handshake is the insurance status ). This State ensures that both parties can end normally, but the problem also arises.

Because of the 2MSL status of the plug-in port (the plug-in Port indicates the IP address and port pair, socket), the application cannot use the same plug-in again in 2MSL time, which is better for the customer program, however, for a service program, such as httpd, it always needs to use the same port for service. In 2MSL time, an error occurs when httpd is started (the plug is used ). In order to avoid this error, the server provides a concept of Calm time, which means that although the server can be restarted in 2MSL time, however, this server still needs to wait for the 2MSL time to complete the next connection.

● CLOSED: No connection status

The passive shutdown end enters the closed state after receiving the ACK package. Connection ended./* The socket is not being used. No connection status */