Status and troubleshooting of TCP connections

By understanding the various states of TCP, we can help to troubleshoot and locate network or system failures. (Summarize content on the network)

1. TCP Status

Before you know TCP, you should know several commands:
Linux View TCP status command: 1), Netstat-nat View the number of TCP states
2), Lsof-i:port can detect open socket status 3), Sar-n SOCK View TCP created Connections 4), Tcpdump-iany TCP port 9000 for TCP ports 9000 for the packet capture
Network test Common command;
1) Ping: Check the network connection is normal or not, mainly testing delay, jitter, packet loss rate.

However, many servers typically turn off the response to pings in order to prevent attacks. So pings are generally used as test connectivity. The ping command receives feedback from the other party, which records the other's IP address and TTL. The TTL is the maximum number of network segments that the field is allowed to pass before the IP packet is discarded by the router. The TTL is a 8 bit field in the IPV4 header. For example, the IP packet before sending the server to set the TTL is 64, you use the ping command, the server feedback information, where the TTL is 56, indicating that a total of 8 routers on the way forward, each through a route, TTL minus 1. 2) Traceroute:raceroute Trace packet arrives the routing tool that the network host passes through traceroute hostname
3) Pathping: is a route tracking tool that combines the functionality of the ping and Tracert commands with other information not provided by the two tools, combining the functionality of both Pathping www.baidu.com
4) MTR: To combine ping nslookup tracert to determine the characteristics of the network 5) Nslookup: Used to resolve the domain name, commonly used to detect the local DNS settings are configured correctly.


LISTENING: Listens for connection requests from a remote TCP port.     First, the server needs to open a socket for listening, the status is listen. To provide a service to be in the listening state, the TCP state change is a port status changes, provide a service to open a port, for example: the WWW service is provided by default is 80 port, the FTP service provides the default port of 21, When the provided service is not connected, it is in the listening state. The FTP service is first in the listening (LISTENING) state after it is started. When listening to the listening state, the port is open, waiting for a connection, but not yet connected. Like the door of your house is open, but no one has come in.
Look at the listening state is the most important thing is to see which ports the machine opened, which programs are open, to close unnecessary ports is a very significant aspect of security, the service port corresponds to a service (application), stop the service to shut down the port, For example, to turn off Port 21, simply stop the FTP service in the IIS service. For information on this, see other articles.
If you unfortunately in the service Port Trojan, Trojan also open a port in the listening state.
Syn-sent: Client syn_sent Status: Waits for a matching connection request after the connection request is sent: the client invokes connect through the application for active open. The client TCP sends a SYN to request a connection. Then the status is set to Syn_sen T./*the socket is actively attempting to establish a connection. Wait for a matching connection request after sending a connection request */
When a connection is requested, the client first sends a synchronization signal to the machine to be accessed, at which time the state is syn_sent, and if the connection succeeds it becomes established, and under normal circumstances the syn_sent state is very short. For example, to access the Web site http://www.baidu.com, if it is normal connection, with TCPView observation IEXPLORE.EXE (IE) established connection will find a quick change from syn_sent to established, indicating a successful connection. Syn_sent the state of the fast may not be seen.
If you find a lot of syn_sent appear, that generally have such a few cases, one is that you want to visit the site does not exist or bad line, the second is scanning software scan a network segment of the machine, there will be a lot of syn_sent, the other is probably the virus, for example, in the "Shock wave", When the virus attacks, it scans other machines, so many syn_sent will appear.


Syn-received: Server-side status SYN_RCVD receive and send a connection request to wait for the other party to confirm the connection request when the server receives a synchronization signal sent by the client, the flag bit ACK and SYN 1 are sent to the client, at which point the server side is in SYN_RCV D State, if the connection succeeds, it becomes established, and under normal circumstances the SYN_RCVD state is very short.
If you find that there are many SYN_RCVD states, your machine may be attacked by a SYN flood DOS (Denial of service attack). The attack principle of SYN Flood is that the attack software sends a SYN connection request (the first step of the handshake) to the attacked server during the three handshake, but the address is forged, such as the attack software randomly forged 51.133.163.104, 65.158.99.152, and so on.     The server sends the flag ACK and SYN 1 to the client (the second step of the handshake) when it receives the connection request, but the IP addresses of these clients are bogus and the server cannot find the client at all, which means that the third step of the handshake cannot be completed. In this case the server side will typically retry (send Syn+ack to the client again) and wait for a period of time to discard the unfinished connection, the length of which we call Syn Timeout, which is generally the order of minutes (approximately 30 seconds-2 minutes) It is not a big problem for a user to have an exception that causes one of the server's threads to wait for 1 minutes, but if a malicious attacker simulates this situation in large numbers, the server will consume very much resources to maintain a very large semi-connected list----Tens of thousands of semi-connections, Even a simple save and traverse can consume a lot of CPU time and memory, not to mention the Syn+ack retry of the IP in this list. At this point, from the normal customer's point of view, the server is out of response, this is what we call doing: the server side received a SYN flood attack (SYN flood attack)


Established: Represents an open connection.      The established state indicates that two machines are transmitting data, and the most important thing to see is which program is in the established state.        The server has many established states: Netstat-nat |grep 9502 or can be detected using lsof-i:9502. Disconnect when the client is not actively close: the fin sent by the client is missing or not sent.

At this time if the client disconnects when the fin packet is sent, the server will be in the close_wait State;

At this time if the client disconnects when the fin packet is not sent, then the service side or display established status;

The resulting client reconnected to the server.

And the new connection on the client (that is, just broken back up) on the server is definitely established; If the client repeats this situation, there will be a large number of fake established connections and close_wait connections on the server side.

The end result is that the new client will not be able to connect, but with Netstat you can still see that a connection has been established and the established is displayed, but the program code is never entered.

Fin-wait-1: Waiting for a remote TCP connection interrupt request, or an acknowledgment of a previous connection interrupt request, the active shutdown (active close) side application calls Close, and its TCP sends a FIN request to actively close the connection before entering the FIN_WAIT1 state./* The S Ocket is closed, and the connection are shutting down. Waiting for a connection interrupt request from a remote TCP, or confirmation of a previous connection interrupt request * * If the server appears shutdown and then restarts, use Netstat-nat to view, you will see a lot of fin-wait-1 status. It is because the server currently has a lot of client connections, directly after shutting down the server, unable to receive the client's ACK.

Fin-wait-2: Waiting for a connection interrupt request from a remote TCP active shutdown after receiving an ACK, it enters the fin-wait-2./* Connection is closed, and the socket was waiting for a shut Down from the remote end. Waiting for a connection interrupt request from remote TCP */This is the state of the well-known semi-shutdown, which is the state after the client and server two-time handshake when the connection is closed. In this state, the application also has the ability to accept data, but it has been unable to send data, but it is also possible that the client has been in a fin_wait_2 state, and the server has been in the Wait_close state, and until the application layer decides to close the state.
Close-wait: Waiting for a connection interrupt request from a local user 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 */

CLOSING: It is rare to wait for a remote TCP acknowledgement of connection interruption./* 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 */

Last-ack: Waiting for the original to be sent to the remote TC