TCP States Defined
Noah Davids This information supplements Noah Davids' article “TCP Connection States -- A Clue to Network Health” that appeared in the June issue of Sys Admin. See Figure 1 for diagram of the state machine. SYN_SENT The SYN_SENT state is entered when a TCP client application on host 1 issues a connection request (active open) to a TCP server application on host 2. The TCP stack on host 1 sends a packet to the TCP stack on host 2 with the synchronization flag set, hence the SYN_SENT state. If there is no server application running on host 2, host 2 will send a RST packet. The TCP client gets an error and no connection is established. If there is a server application running and it can accept connections, host 2 will send a SYN-ACK packet. When host 1 receives the SYN-ACK packet, it sends back an ACK packet and moves the connection state to ESTABLISHED. So what does it mean if the connection stays in the SYN_SENT state? It means that host 1 never got the SYN-ACK packet from host 2. SYN_RCVD This state is the mirror image of SYN_SENT, so the roles of host 1 and host 2 are reversed. The SYN_RCVD state is entered on host 1 when a SYN packet is received from host 2 for a server application that host 2 thinks is running on host 1. As discussed above, if there is no server application running on host 1, host 1 will respond with an RST packet, and no connection is established. If there is a server application, and it can accept the connection request, host 1 replies with a SYN-ACK packet. Once host 2 gets the SYN-ACK, it moves its state from SYN_SENT to ESTABLISHED and sends an ACK packet back to host 1. Once host 1 receives the ACK packet, it moves its state from SYN_RCVD to ESTABLISHED. So what does it mean if a connection remains in the SYN_RCVD state? It means that host 1 never got the ACK packet from host 2. FIN_WAIT_1 This state is entered when the application on host 1 closes the connection and sends host 2 a FIN packet. Host 2 should respond with an ACK packet. When host 1 receives the ACK packet, it moves the state to FIN_WAIT_2. What does it mean if a connection remains in the FIN_WAIT_1 state? It means that host 1 never got the ACK packet from host 2. FIN_WAIT_2 When host 1 receives an ACK packet from host 2 for the FIN packet that host 1 sent to host 2, the state changes to FIN_WAIT_2. In the FIN_WAIT_2 state, host 1 waits for host 2 to send a FIN packet. There is no time limit by which host 2 must send its FIN. Indeed, there is no requirement that it send a FIN at all. The FIN will be sent when the application on host 2 shuts down its side of the connection. So, a connection can be stuck in FIN_WAIT_2 forever. Many TCP stacks have implemented timeouts for these connections, but it's not a requirement from TCP. What does it mean if the connection remains in the FIN_WAIT_2 state? It means that host 1 never got a FIN packet from host 2. CLOSING The CLOSING state is entered when both the host 1 and host 2 applications close their connections at almost the same time. Host 1 sends its FIN and then waits for its ACK, but instead it receives a FIN from host 2. At that point, it enters the CLOSING state. It still must wait for the ACK of its FIN, so in that respect having a connection in the CLOSING state is the same as having it in the FIN_WAIT_1 state. CLOSE_WAIT A connection in CLOSE_WAIT has received a FIN from host 2, ACKed the FIN packet, and sent a notification to the local application that the connection has been closed by host 2. The TCP stack now waits for the local application to close the connection, so it can send host 2 its own FIN packet. What does it mean if the connection remains in the CLOSE_WAIT state? It means that the local application has not closed the connection after being notified that the application on host 2 has closed its side of the connection. |