Introduction: TCP Connection States
A TCP connection progresses through a defined sequence of states. An endpoint changes state in response to an event, such as an application request, an incoming segment with a control flag, an acknowledgment, or an expired timer. The state records which operations and transitions are valid at that point.
The Transmission Control Protocol (TCP) manages connections with this structured state model. Reliability and ordered delivery require the endpoint to track sequence numbers, acknowledgments, outstanding control segments, and timers. The formal set of states and transitions is known as the TCP state machine.
The model is a . At a given moment, a TCP control block is represented by one state from a limited, defined set. Transitions are triggered by events such as an application requesting a connection, receiving a segment with a particular flag, receiving an acknowledgment, or a timer expiring. The state machine makes the handshake, data transfer, and orderly close interoperable between endpoints. Each endpoint runs its own instance of the model, so the two sides can temporarily occupy different states during a handshake or close. A transition also updates sequence variables, retransmission timers, and the actions required for the next event.
State Diagram: TCP Connection Lifecycle
The diagram shows the states defined for a TCP connection and the events that cause transitions between them. Each state has defined entry and exit conditions. An arrow represents a transition after the corresponding event has been processed; the diagram does not prescribe one fixed path for every connection.
A typical active opener uses SYN-SENT and later a FIN-WAIT state. A passive opener usually starts in LISTEN and can enter CLOSE-WAIT after receiving a FIN. ESTABLISHED is the data-transfer state in which both endpoints may exchange application bytes. The diagram also represents less common paths, including simultaneous open, simultaneous close, retransmission-related events, and an abort with RST. A missing segment does not itself create a new state; timers and later segments drive the next transition.
TCP States: Detailed Description
Each state description gives its purpose, common entry event, and relevant exit transition. The terminology follows the TCP specification. The names describe local TCP behavior, so labels such as active closer refer to the endpoint that sends the first FIN. An application may close one direction while the peer continues to send data, which explains why the termination states are separate. The state machine tracks transport control, while application authentication, message framing, and request semantics belong to higher layers.
CLOSED
Condition: No active TCP control block represents a connection.
CLOSED is the state with no connection. An endpoint is in this state before it opens or listens, and it returns to CLOSED after the connection has been fully terminated. It is included in the TCP state model even though it represents the absence of an active connection. No sequence space or peer-specific retransmission state is active in CLOSED, so an incoming segment is handled according to the rules for an absent connection.
LISTEN
Role: Endpoint performing a passive open.
Condition: Waiting for an incoming SYN.
This state represents an endpoint prepared to accept an incoming connection. A server application, such as a web server, binds to a port such as 443 for HTTPS and passively waits for a client to initiate a connection.
Transition:It enters LISTEN from CLOSED after the application calls 'listen()'. It enters 'SYN_RCVD' after receiving an incoming SYN.
SYN-SENT
Role: Endpoint performing an active open.
Condition: A SYN has been sent and a response is pending.
An endpoint enters this state after sending a SYN to request a connection. It is actively establishing the connection and waits for a SYN-ACK or another valid response from the peer.
Transition:It enters SYN-SENT from CLOSED when an application initiates a connection. After receiving a SYN-ACK, it sends an ACK and enters 'ESTABLISHED'. If a SYN arrives at the same time as the active open, simultaneous open leads to 'SYN_RCVD'.
SYN-RCVD
Role: Endpoint that has replied to a SYN.
Condition: A SYN-ACK has been sent and the final ACK is pending.
An endpoint enters this state after receiving a SYN and sending its own SYN-ACK. It has recorded the peer's synchronization information and waits for the ACK that completes the three-way handshake.
Transition:It normally enters from 'LISTEN' after receiving a SYN. It enters 'ESTABLISHED' after receiving the final ACK. A simultaneous open can also pass through this state.
ESTABLISHED
Role: Both endpoints.
Condition: The handshake is complete and data transfer is permitted.
ESTABLISHED is the main data-transfer state. After the three-way handshake, both endpoints can send and receive application bytes in both directions. The state normally lasts for the data-transfer phase, with sequence numbers, acknowledgments, flow control, and congestion control active.
Transition:Either endpoint can leave this state by sending a FIN. The sender enters 'FIN_WAIT_1', while the endpoint receiving the FIN acknowledges it and enters 'CLOSE_WAIT'. An abort can instead terminate the connection with an RST.
The Connection Termination States
A typical orderly TCP close uses four control exchanges, but simultaneous close and abort with RST follow different transitions. The termination states manage the ordinary exchange. The endpoint that sends the first FIN is the "active closer"; the endpoint that receives it is the "passive closer." A FIN consumes one sequence number and confirms the end of one byte stream direction. ACK processing and timer expiration determine when the control block can be removed.
FIN-WAIT-1
Role: Active closer.
Condition: A local FIN has been sent and its ACK is pending.
The local application has indicated that it has no more data to send in this direction and has requested a close. The TCP stack sends a FIN to the peer and enters this state while waiting for an acknowledgment of that 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.
Condition: The local FIN was acknowledged; the peer FIN is pending.
The local machine has received the acknowledgment for its FIN. Its sending direction is closed, while it can still receive data until the peer sends its FIN. It waits for that FIN to close the other direction.
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.
Condition: A peer FIN was received and acknowledged; local close is pending.
The local machine has received a FIN and sent an ACK. The receive direction is closed, while the local application may finish sending its remaining data. The application has been notified and must eventually close its own direction.
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.
Condition: The local FIN was sent after a peer FIN; its ACK is pending.
The local machine has sent its own FIN after the application closed its direction and now waits for the final ACK for that FIN.
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.
Condition: The final FIN was received and acknowledged; the close timer is running.
After receiving the peer's FIN and sending the final ACK, the endpoint that initiated the close enters TIME-WAIT. It remains there for . RFC 9293 defines MSL as two minutes for its specification, while implementations can use timestamp-based timer optimizations.
Purpose:This period has two purposes: 1) It allows the endpoint to retransmit the final ACK if the peer retransmits its FIN after losing that ACK. 2) It prevents delayed duplicate segments from being confused with a later connection that reuses the same address and port tuple. After the timer expires, the endpoint transitions to 'CLOSED'.
CLOSING
Role: Both endpoints during simultaneous close.
Condition: Each FIN arrived before the ACK for the local FIN.
This state occurs when both endpoints actively close at about the same time and their FIN segments cross. Each side sends a FIN and receives the peer FIN before its own FIN is acknowledged. After the local FIN is acknowledged, the endpoint transitions to TIME-WAIT.
Connection Lifecycle: Worked Sequence
The table follows a typical web request in which the client initiates an orderly close. It shows how the endpoint states change after each handshake, data-transfer, and termination event.
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 |