TCP State Machine
The full TCP finite state machine: LISTEN, SYN-SENT, ESTABLISHED, FIN-WAIT, CLOSE-WAIT, LAST-ACK, TIME-WAIT transitions.
Introduction: The Rules of a Polite Conversation
Think about the lifecycle of a simple phone call. It does not just instantly happen. There is a clear sequence of states: your phone is idle, you dial, the other end rings, someone answers, you talk, you say goodbye, they say goodbye, and you both hang up. Each of these steps is a distinct state, and you move from one state to the next based on specific events (dialing, answering, hanging up).
The Transmission Control Protocol (TCP) manages its connections in a very similar, highly structured way. Because TCP promises reliability and order, it cannot simply start and stop sending data randomly. It needs a formal rulebook that defines every possible phase of its existence, from the moment it is created until it is completely torn down. This rulebook is known as the TCP State Machine.
It is a type of , which is a formal way of saying that a TCP connection can only exist in one of a limited, well-defined set of states at any given moment. The transitions between these states are triggered by specific events, such as an application requesting a connection, receiving a data packet with a particular flag set, or a timer expiring. Understanding this state machine is key to understanding how TCP achieves its legendary reliability.
The State Diagram: A Map of the Connection Lifecycle
The entire lifecycle of a TCP connection can be visualized in a single diagram. This diagram shows all possible states and the events that cause a transition from one state to another. While it may look complex at first, we will break it down state by state in the sections that follow. The arrows represent the flow of the connection based on events.
The typical path for a client involves states like SYN-SENT and FIN-WAIT, while a server typically goes through states like LISTEN and CLOSE-WAIT. The ESTABLISHED state is the goal, where both parties can exchange data.
Detailed Breakdown of TCP States
Let us explore each state in the diagram, explaining its purpose, how to enter it, and how to leave it.
CLOSED
Analogy: The phone is on the hook, not in use.
This is not technically a state but rather the starting and ending point. It represents the absence of a connection. A connection starts in the CLOSED state before any attempt to connect is made, and it returns to the CLOSED state after it has been fully terminated.
LISTEN
Role: Server only.
Analogy: Waiting for the phone to ring.
This state represents a server that is ready to accept an incoming connection. A server application, like a web server, binds itself to a specific port number (e.g., port 443 for HTTPS) and enters the LISTEN state, passively waiting for a client to initiate a connection.
Transition: It enters this state from CLOSED after the application calls 'listen()'. It will transition to 'SYN_RCVD' upon receiving an incoming SYN packet.
SYN-SENT
Role: Client only.
Analogy: You have just dialed the number and are waiting for someone to answer.
A client enters this state after sending a SYN (Synchronize) packet to the server to request a connection. The client is now actively trying to establish a connection and is waiting for a response from the server (a SYN-ACK packet).
Transition: It enters from CLOSED when an application initiates a connection. If it receives a SYN-ACK, it sends an ACK and transitions to 'ESTABLISHED'. If it receives a SYN from the other side at the same time (a simultaneous open), it transitions to 'SYN_RCVD'.
SYN-RCVD
Role: Server mostly.
Analogy: You have answered the ringing phone and said "Hello?", and are now waiting for the caller to respond.
A server enters this state after it has received a SYN request from a client and has sent back its own SYN-ACK response. The server has acknowledged the client-s request and sent its own synchronization information. It is now waiting for the final ACK from the client to complete the three-way handshake.
Transition: It enters from 'LISTEN' after receiving a SYN. It transitions to 'ESTABLISHED' upon receiving the final ACK from the client.
ESTABLISHED
Role: Client and Server.
Analogy: Both parties are on the line and can now have a conversation.
This is the primary state of a TCP connection. Once the three-way handshake is complete, both the client and server enter the ESTABLISHED state. This means the connection is fully open, and application data can be sent and received in both directions. The connection remains in this state for the entire duration of the data transfer phase.
Transition: Both sides enter this state after the three-way handshake completes. The connection will leave this state when either side decides to close it by sending a FIN packet. The one that sends the FIN transitions to 'FIN_WAIT_1'. The one that receives the FIN transitions to 'CLOSE_WAIT'.
The Connection Termination States
Closing a TCP connection is a graceful, four-step process. The following states manage this termination. The side that starts the closing process is called the "active closer," while the other side is the "passive closer."
FIN-WAIT-1
Role: Active Closer.
Analogy: You have just said, "Okay, I am done talking, goodbye," and are waiting for the other person to acknowledge they heard you.
The application on the local machine has signaled that it has no more data to send and has requested to close the connection. The TCP stack sends a FIN packet to the other end and enters this state, waiting for an acknowledgment (ACK) of its FIN.
Transition: It enters from 'ESTABLISHED' after the local application closes the connection. Upon receiving an ACK from the other side, it transitions to 'FIN_WAIT_2'.
FIN-WAIT-2
Role: Active Closer.
Analogy: The other person said, "Okay, I heard you say goodbye." Now you are quietly waiting for them to finish their last words and say goodbye too.
The local machine has received the acknowledgment for its FIN packet. Its sending direction is now closed. It now waits for a FIN packet from the other end to close the other direction of the connection.
Transition: It enters from 'FIN_WAIT_1' after receiving an ACK for its FIN. It will transition to 'TIME_WAIT' upon receiving a FIN packet from the other side.
CLOSE-WAIT
Role: Passive Closer.
Analogy: You have heard the other person say goodbye. You have replied "Okay," but you still have a few last things to say before you hang up.
This state represents the passive side of the termination. The local machine has received a FIN packet from the other end and has sent back an ACK. This means the connection is now "half-closed." The local application has been notified that the other side is finished, and it should now finish its work and close the connection from its end.
Transition: It enters from 'ESTABLISHED' after receiving a FIN packet. It transitions to 'LAST_ACK' after its own application issues a close command.
LAST-ACK
Role: Passive Closer.
Analogy: You have finished your last words and have now also said, "Okay, goodbye from me too." You are just waiting for one final confirmation before you hang up.
The local machine has sent its own FIN packet to the other end (after its application has closed the connection) and is now waiting for the final acknowledgment (ACK) for its FIN packet.
Transition: It enters from 'CLOSE_WAIT' after sending its own FIN. Upon receiving the final ACK, it transitions to 'CLOSED'.
TIME-WAIT
Role: Active Closer.
Analogy: You have heard the final goodbye and sent your final confirmation. You are holding the phone to your ear for just a little while longer to make sure the line is truly dead and there are no echoes.
This is a crucial final state for the side that initiated the close. After receiving the final FIN from the other side and sending its final ACK, the connection enters the TIME-WAIT state. It will remain in this state for a period of (two times the Maximum Segment Lifetime, typically 30 to 120 seconds).
Purpose: This waiting period serves two purposes: 1) It ensures the final ACK sent was received. If it was lost, the other side will retransmit its FIN, which will be received during TIME-WAIT, and a new ACK can be sent. 2) It allows any old, delayed duplicate packets still lingering in the network to die out, preventing them from corrupting a new connection that might later use the same IP addresses and port numbers. After the timer expires, the connection transitions to 'CLOSED'.
CLOSING
Role: Both (in rare cases).
Analogy: Both people say "goodbye" at the exact same time.
This is a relatively uncommon state that occurs when both sides of a connection decide to actively close at the same time, and their FIN packets cross each other in the network. Each side sends a FIN and then receives a FIN before receiving the ACK for its own FIN. After receiving the acknowledgment for its own FIN, the connection will transition to the TIME-WAIT state.
Tying It Together: The Lifecycle in Action
Let us walk through a complete, typical lifecycle of a web request to see how these states connect.
Typical Connection (Client initiates close)
| Step | Event | Client State | Server State |
|---|---|---|---|
| 1 | Server starts listening | CLOSED | LISTEN |
| 2 | Client connects, sends SYN | SYN-SENT | LISTEN |
| 3 | Server receives SYN, sends SYN-ACK | SYN-SENT | SYN-RCVD |
| 4 | Client receives SYN-ACK, sends ACK | ESTABLISHED | SYN-RCVD |
| 5 | Server receives ACK (Data Transfer) | ESTABLISHED | ESTABLISHED |
| 6 | Client application closes, sends FIN | FIN-WAIT-1 | ESTABLISHED |
| 7 | Server receives FIN, sends ACK | FIN-WAIT-1 | CLOSE-WAIT |
| 8 | Client receives ACK for its FIN | FIN-WAIT-2 | CLOSE-WAIT |
| 9 | Server application closes, sends FIN | FIN-WAIT-2 | LAST-ACK |
| 10 | Client receives FIN, sends ACK | TIME-WAIT | LAST-ACK |
| 11 | Server receives final ACK | TIME-WAIT | CLOSED |
| 12 | Client's 2MSL timer expires | CLOSED | CLOSED |