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

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 will also open a port in the listening state.

syn-sent: Client syn_sent Status:Wait for a matching connection request after sending the connection request: the client calls connect through the application for active open. The client TCP sends a SYN to request a connection. The status 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 */
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 waits for confirmation of the connection request after receiving and sending a connection request. When the server receives the synchronization signal sent by the client, the flag bit ACK and SYN 1 are sent to the client, and the server side is in the SYN_RCVD state, and if the connection succeeds, it becomes established, and under normal circumstances 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 a normal customer's point of view, the server is out of response, this situation we call doing:SYN flood attack on server side (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: waits for a remote TCP connection to interrupt the request, or an acknowledgement of a previous connection interruption request. The active close side application calls close, and its TCP sends a FIN request to actively close the connection and then enters 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 */

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 sh Utdown 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 userAfter the passive shutdown (passive close) side 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 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: Waiting for remote TCP to confirm connection interruptionRelatively uncommon./* 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 acknowledgement of the original connection interrupt request to the remote TCPAfter 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 */

time-wait: Wait enough time to ensure that the remote TCP receives a connection interrupt request acknowledgementAfter the active shut-off side receives fin, TCP sends an 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 acknowledgement */time_wait wait state, which State is also called the 2MSL state, that is, after Time_wait2 sent the last ACK datagram, to enter the TIME_WAIT state, this state is to prevent the last handshake of the datagram is not transmitted to the other side of the preparation (note that this is not a four-time handshake, This is the fourth time that the handshake is insured). This state is to a large extent guaranteed that both sides can end normally, but the problem also comes.
Due to the 2MSL status of the socket (socket is the meaning of IP and port pairs, socket), so that the application in 2MSL time is unable to use the same socket again, for the client program is good, but for the service program, such as httpd, it always use the same port to service, In 2MSL time, the boot httpd will be error (socket is used). To avoid this error, the server gives the concept of a quiet time, which means that in 2MSL time, although the server can be restarted, but the server will still wait for 2MSL time in the past before the next connection. For details, please see:Time_wait caused cannot assign requested address error

CLOSED: There is no connection status the passive shut-off side enters the CLOSED state after receiving the ACK packet. The connection ends./* The socket is not being used. No connection Status */

2. TCP State Migration Roadmap

Client/server Two routes describe the TCP state Migration roadmap:

This is a seemingly complex state migration diagram, because it contains two parts---the state migration of the server and the State migration of the client, if from a certain point of view this figure, it will be clear that the server and the client is not absolute, the data is sent to the client, The server is the one that accepts the data.

State Migration diagram for client applications the state of the client can be represented by the following process: closed->syn_sent->established->fin_wait_1->fin_wait_2- >time_wait->closed above process is in the program normal situation should have the process, from the diagram in the book can be seen, when the connection is established, when the client receives the ACK of the SYN message, the client opens the data to connect interactively. The end-of-connection is usually the client's active end, and after the client finishes the application, it needs to go through the state of Fin_wait_1,fin_wait_2, which is the four-time handshake of the end connection mentioned earlier.

The status of the server State Migration diagram The state of the server can be represented by the following process:Closed->listen->syn received->established->close_wait->last_ Ack->closed When a connection is established, the server side enters the data interaction state after the third handshake, and the close connection is after the second handshake of the connection is closed (note that it is not the fourth time). After closing, it waits for the client to give the final ACK packet in order to enter the initial state.
other state migrations also have some other state migrations, which are summarized below for both the server and the client listen->syn_sent, which is simple enough for the server to open the connection at times. Syn_sent->syn received, the server and the client in the Syn_sent state if received SYN datagram, you need to send the SYN ACK datagram and adjust its state to the SYN received state, ready to enter the established syn_sent- >closed, in the case of a send timeout, is returned to the CLOSED state. Syn_ receives->listen, if received by the RST packet, it returns to the LISTEN state. Syn_ received->fin_wait_1, this migration is said, can not go to established state, and can jump directly to the fin_wait_1 state and wait to close.

3, TCP connection to establish three times handshake

TCP is a connection-oriented protocol, so it is necessary to first establish a connection before sending data to both parties. Client Connection server:
When the client side invokes the socket function call, the client side produces a socket in the closed state.
(1) The first handshake: the client side also calls the Connect function call, the system for the client randomly assigned a port, along with the parameters in the incoming connect (server IP and Port), which formed a connection four tuples, The client sends a TCP message with a SYN flag to the server. This is the message 1 in the three-time handshake process. The connect call allows the client side socket to be in the syn_sent state, waiting for the server to confirm; SYN: Synchronous sequence Number (Synchronize Sequence Numbers).

(2) The second handshake: the server receives the SYN packet, must confirm the customer's SYN (ACK=J+1), simultaneously also sends a SYN packet (syn=k), namely the Syn+ack packet, at this time the server enters the SYN_RECV state;

(3) The third handshake: the client receives the server's Syn+ack packet, sends the acknowledgment packet ack (ACK=K+1) to the server, the packet is sent, the client and the server enter the established state, and the handshake is completed three times. The connection is ready for read and write operations.

A full three-time handshake is also: request---answer---confirm again.

The TCP protocol completes the establishment of the connection through three message segments, which is called a three-time handshake (three-way handshake), as shown in the process. The corresponding function interface:

4. Termination of TCP connection (four handshake release)

Because TCP connections are full-duplex, each direction must be closed separately. The principle is that when a party completes its data sending task, it can send a fin to terminate the connection in this direction. Receiving a fin only means there is no data flow in this direction, and a TCP connection can still send data after receiving a fin. The first party to close will perform an active shutdown, while the other side performs a passive shutdown.

Establishing a connection requires three handshakes, while terminating a connection takes four handshakes, which is caused by a semi-shutdown of TCP (Half-close),

(1) Client A sends a fin to turn off customer A to Server B data Transfer (message segment 4).

(2) Server B receives this fin, which sends back an ACK, confirming that the serial number is received plus 1 (message Segment 5). As with Syn, a fin will occupy a sequence number.

(3) Server B closes the connection to client A and sends a fin to client a (message segment 6).

(4) Client A sends back ACK message confirmation, and sets the confirmation serial number to receive the serial number plus 1 (message segment 7).

corresponding function interface

The calling process is as follows:

1) When the client wants to close the connection between it and the server. The client (an application process) first calls close to actively close the connection, when TCP sends a FIN m;client end in the Fin_wait1 state.
2) When the server side receives the fin m, the passive shutdown is performed. The fin is confirmed and returned to the client ACK. When the server side returns to the client ACK, the client is in the FIN_WAIT2 state and the server is in the close_wait state. Its reception is also passed as a file terminator to the application process, because the receive of fin means that the application process can no longer receive additional data on the corresponding connection;
3) After a period of time, when the server side detects the client side of the shutdown operation (read returns to 0). A server-side call that receives a file terminator close closes its socket. This causes TCP on the server side to also send a fin N; At this point the server's status is Last_ack.
4) When the client receives fin from the server. The client-side socket is in the TIME_WAIT state, and it sends an ACK acknowledgement to the server side, which is in the closed state when the server side receives an ACK acknowledgement.
So there is a fin and an ack in each direction.

1. Why is a connection agreement a three-time handshake, and a four-time handshake when the connection is closed?

This is because the socket in the listen state of the server is sent in a message after it receives a request for the connection of the SYN message, and it can put the ACK and SYN (ACK response, and SYN synchronous). However, when the connection is closed, when receiving the other's fin message notification, it simply means that no data is sent to you, but not all of your data are sent to the other side, so you may not immediately close the socket, that is, you may also need to send some data to the other side, Send the FIN message to the other side to show that you agree that you can now close the connection, so it is here that the ACK message and fin messages are sent separately in most cases.

2. Why does the time_wait state need to wait 2MSL before returning to the closed state?

This is because although both sides agree to close the connection, and the handshake of the 4 messages are also coordinated and sent over, it can be directly back to the closed state (as from the Syn_send state to establish State):

On the one hand, the termination of the TCP full-duplex connection is reliable, that is, when the last Ack is lost, the passive shut-off side will resend fin, so the active shutdown needs to maintain state information to allow it to resend the final ack.

On the other hand, however, since we have to assume that the network is unreliable, you cannot guarantee that the last ACK message you send will be received by the other party, so the socket in the Last_ack state may be re-sending the fin message because the timeout does not receive an ACK message, so this time_ The wait state is used to re-send an ACK message that may be lost.

TCP during 2MSL Wait, define this connection (4 tuples) can no longer be used, any late messages will be discarded. Imagine that if there is no 2MSL limit, just the new connection satisfies the original 4-tuple, the connection may receive a delay message on the network may interfere with the newly established connection.

Status and troubleshooting of TCP connections