how/network

TCP states: all 11 states

When you look at `ss -tn`, you do not see only ESTABLISHED. SYN_SENT, FIN_WAIT_1, TIME_WAIT: what do they mean and why do they "hang"?

Every TCP connection in your system is in one of 11 states at any given moment. It is a finite state machine. Transitions happen on network events (recv SYN, send FIN) and system calls (connect(), close()).

The output of ss -tn or netstat -tan is a "dump of this machine" for every live connection on the host. When you see SYN_SENT or TIME_WAIT there, that is a specific position in the state machine.

Press ▶ to walk through the full life cycle of one connection, from the first CLOSED to the final CLOSED, showing the state of both sides in sync.

step 1/11·00 · both sides in CLOSED

§ steps

No sockets are open. This is the "default" state for every connection, until the application calls socket() + connect() or socket() + bind() + listen().

You will not see this state in ss. ss shows only the active entries in the kernel TCP table.

recap

What to remember:

A TCP connection is a separate finite state machine on each side. One side can be in CLOSE_WAIT while the other is in FIN_WAIT_2. That is normal, the two are consistent with each other
Almost every "stuck" state is a symptom:
- SYN_SENT forever → the server is not responding (firewall / closed port)
- many SYN_RECEIVED → a SYN-flood DDoS attack or a full backlog
- many TIME_WAIT → a recent mass close of connections (normal)
- many CLOSE_WAIT → a bug in the application: it received the FIN but never called close(). A socket leak
TIME_WAIT lasts 2×MSL (60-120 sec). This makes sure that late packets from the old connection do not land in a new one with the same 4-tuple (src/dst IP+port). On high-throughput hosts you tune net.ipv4.tcp_tw_reuse
Not shown in the animation: CLOSING and simultaneous open, rare cases where both sides initiate close/open at the same time. They almost never happen in practice
The command ss -t state established (or time-wait, syn-sent, and so on) filters by a specific state, handy for debugging

See also [[tcp-handshake|the handshake itself]] and [[tcp-retransmission|retransmission]]. They show why the transitions are exactly these and what happens to the packets.

§ dig into the knowledge base

§ steps

No sockets are open. This is the "default" state for every connection, until the application calls socket() + connect() or socket() + bind() + listen().

You will not see this state in ss. ss shows only the active entries in the kernel TCP table.