Connection Lifecycle
ss -tan can show a socket sitting idle for a minute or more after your program moved on, still holding its place so a late-arriving byte from the old conversation cannot land in a new one.
- ▸Opening took three packets; closing takes four, because each of the two directions must be shut on its own.
- ▸Only the initiating side pays the lingering wait; the other is done the moment its last ACK lands.
- ▸A pile of stuck-open sockets is never the peer's fault: your own program received the goodbye and never called
close().
A live TCP connection is really two byte streams sharing one socket pair, one flowing each way, and they are independent. So closing is not one act. The client sends a FIN: I have no more bytes for you. The server acknowledges it, and now that one direction is shut, yet the server can still send. Only when the server sends its own FIN, and the client acknowledges that, is the connection fully down.
Count them: FIN, ACK, FIN, ACK. Four packets, where opening took three, because the two directions cannot be folded together the way the open could. Between that opening FIN and the last, the connection sits in a real, named middle state, half-closed: one direction done, the other still carrying data. A single FIN never closes a connection. It closes a direction.