Appendix A. TCP Connection State Diagram
This appendix provides a detailed illustration of TCP connection state transitions.
TCP State Transition Diagram
+---------+
| CLOSED |
+---------+
|
(passive OPEN)
|
v
+---------+
| LISTEN |
+---------+
(rcv SYN) | ^ (CLOSE)
| |
v |
+---------+
|SYN RCVD|
+---------+
(rcv ACK)|
|
(active OPEN) v
+---------+ +---------+
|SYN SENT |`<---->`| ESTAB |
+---------+ +---------+
| |
| (CLOSE/FIN)
| |
| v
| +---------+
| |FIN WAIT1|
| +---------+
| (rcv ACK) |
| |
| v
| +---------+
| |FIN WAIT2|
| +---------+
| (rcv FIN) |
| |
| v
| +---------+
| |TIME WAIT|
| +---------+
| (timeout) |
| |
| v
| +---------+
+---------->| CLOSED |
+---------+
Simultaneous Close: Passive Close:
FIN WAIT1 --rcv FIN--> CLOSING ESTABLISHED --rcv FIN--> CLOSE WAIT
CLOSING --rcv ACK--> TIME WAIT CLOSE WAIT --CLOSE--> LAST ACK
LAST ACK --rcv ACK--> CLOSED
State Descriptions
CLOSED
- Fictional state representing no TCB (Transmission Control Block), thus no connection
- This is the starting and ending point for all connections
LISTEN
- Server waiting for connection request from any remote TCP
- Passive open state
SYN-SENT
- Client waiting for matching connection request after sending SYN
- Active open state
SYN-RECEIVED
- Server waiting for ACK after receiving SYN and sending SYN-ACK
- Middle state of three-way handshake
ESTABLISHED
- Connection is established, data transfer can occur
- This is the normal state during the data transfer phase
FIN-WAIT-1
- Active closer waiting for ACK or FIN from remote
- First state of connection termination
FIN-WAIT-2
- Waiting for FIN from remote after receiving ACK for sent FIN
- Indicates local side will no longer send data, but can still receive
CLOSE-WAIT
- Passive closer waiting for local application to close after receiving FIN
- Can still send data at this point
CLOSING
- State during simultaneous close
- Waiting for ACK of FIN from remote
LAST-ACK
- Passive closer waiting for ACK after sending FIN
- Goes directly to CLOSED after receiving ACK
TIME-WAIT
- Active closer enters this state after receiving FIN from remote and sending ACK
- Waits for 2MSL (Maximum Segment Lifetime)
- Purposes:
- Ensure final ACK reaches remote
- Prevent old segments from interfering with new connections
Key State Transitions
Connection Establishment (Three-Way Handshake)
CLOSED --> (active open) --> SYN-SENT
SYN-SENT --> (receive SYN-ACK) --> ESTABLISHED
CLOSED --> (passive open) --> LISTEN
LISTEN --> (receive SYN) --> SYN-RECEIVED
SYN-RECEIVED --> (receive ACK) --> ESTABLISHED
Connection Closure (Four-Way Handshake)
Active Close:
ESTABLISHED --> (send FIN) --> FIN-WAIT-1
FIN-WAIT-1 --> (receive ACK) --> FIN-WAIT-2
FIN-WAIT-2 --> (receive FIN) --> TIME-WAIT
TIME-WAIT --> (2MSL timeout) --> CLOSED
Passive Close:
ESTABLISHED --> (receive FIN) --> CLOSE-WAIT
CLOSE-WAIT --> (application close) --> LAST-ACK
LAST-ACK --> (receive ACK) --> CLOSED
Simultaneous Open
CLOSED --> (send SYN) --> SYN-SENT
SYN-SENT --> (receive SYN) --> SYN-RECEIVED
SYN-RECEIVED --> (receive ACK) --> ESTABLISHED
Simultaneous Close
ESTABLISHED --> (send FIN) --> FIN-WAIT-1
FIN-WAIT-1 --> (receive FIN) --> CLOSING
CLOSING --> (receive ACK) --> TIME-WAIT
TIME-WAIT --> (2MSL timeout) --> CLOSED
Importance of TIME-WAIT State
Why is TIME-WAIT Needed?
-
Ensure Reliable Closure:
- If final ACK is lost, remote will retransmit FIN
- TIME-WAIT state ensures ability to respond to retransmitted FIN
-
Prevent Old Connection Interference:
- Delayed old segments may exist in the network
- Waiting 2MSL ensures old segments disappear from network
- Prevents old segments from being mistaken as valid data by new connections
2MSL Time:
- MSL (Maximum Segment Lifetime): Maximum time a segment can live in the network
- Typically MSL = 2 minutes
- Therefore TIME-WAIT = 2MSL = 4 minutes
- Some implementations use shorter times (e.g., 30 or 60 seconds)
Note: For complete state transition logic and boundary case handling, refer to the full specification in RFC 9293.