client-side socket state 

• Server creates listening socket, binds it, etc.
• Server calls accept
• Client calls connect creating the connection (TCP state on both sides moves to ESTABLISHED
• send / recv / send / recv / etc (state still ESTABLISHED)
• Client calls close; client OS sends FIN packet to server (client OS moves socket state to FIN_WAIT1)
• Server OS sends ACK to acknowledge the client machine’s FIN (server OS moves socket state to CLOSE_WAIT; client OS moves socket state to FIN_WAIT2)
• Server (program) never closes its socket, and hence server OS never sends FIN, so client OS will maintain the socket in FIN_WAIT2 state. (Server socket state says in CLOSE_WAIT)

The client-side socket state could stay in FIN_WAIT2 state for a long time, or even forever, depending on the OS implementation. Linux, for example, has a tunable variable tcp_fin_timeout that specifies how long an otherwise idle connection will remain in FIN_WAIT2; but the TCP standard does not specify a time-out for FIN_WAIT2. (Note that the client program is not aware of any of this. It has closed the socket, the socket file descriptor has been destroyed and the socket is no longer accessible to it; this is all handled by the operating system.)