how/network

TCP states - все 11 состояний

Когда смотришь `ss -tn` - там не только ESTABLISHED. SYN_SENT, FIN_WAIT_1, TIME_WAIT - что они значат и почему «висят»?

Каждое TCP-соединение в твоей системе в любой момент времени находится в одном из 11 состояний. Это конечный автомат - переходы происходят на сетевые события (recv SYN, send FIN) и системные вызовы (connect(), close()).

Вывод ss -tn или netstat -tan - это и есть «дамп этого автомата» для всех живых соединений на хосте. Когда видишь там SYN_SENT или TIME_WAIT - это конкретная позиция в state machine.

Нажми ▶ - пройдём по полному жизненному циклу одного соединения от первого CLOSED до финального CLOSED, синхронно показывая в каком состоянии обе стороны.

step 1/11·00 · обе стороны в CLOSED

§ шаги

Никаких сокетов не открыто. Состояние «по умолчанию» для всех соединений - пока приложение не вызвало socket() + connect() или socket() + bind() + listen().

В ss ты этого состояния не увидишь - ss показывает только активные записи в TCP-таблице ядра.

итого

Что важно запомнить:

TCP-соединение - это отдельный конечный автомат на каждой стороне. Одна сторона может быть в CLOSE_WAIT, другая в FIN_WAIT_2 - это нормально, они согласованы между собой
Почти все «застрявшие» состояния - это симптомы:
- SYN_SENT навсегда → сервер не отвечает (фаервол / порт закрыт)
- SYN_RECEIVED много → DDoS-атака SYN-flood'ом или backlog забит
- TIME_WAIT много → недавнее массовое закрытие коннектов (нормально)
- CLOSE_WAIT много → баг в приложении: получили FIN, но не вызвали close(). Утечка сокетов
TIME_WAIT длится 2×MSL (60-120 сек). Это нужно чтобы запоздавшие пакеты от старого соединения не попали в новое с тем же 4-tuple (src/dst IP+port). На high-throughput хостах настраивают net.ipv4.tcp_tw_reuse
Не показанные на анимации CLOSING и simultaneous open - редкие сценарии когда обе стороны одновременно инициируют close/open. В реальности почти не встречаются
Команда ss -t state established (или time-wait, syn-sent и т.д.) фильтрует по конкретному состоянию - удобно для дебага

Связано с [[tcp-handshake|самим handshake'ом]] и [[tcp-retransmission|retransmission]] - там показано почему именно такие переходы и что происходит с пакетами.

§ копнуть в базу знаний

§ шаги

Никаких сокетов не открыто. Состояние «по умолчанию» для всех соединений - пока приложение не вызвало socket() + connect() или socket() + bind() + listen().

В ss ты этого состояния не увидишь - ss показывает только активные записи в TCP-таблице ядра.