Вопрос по tcp/ip

полагаю, сервер пошлет ФИН сегмент еще раз. А там уж ему или ответят ресетом, или пройдет retransmit timeout.

Ну вот допусти противоположный хост лёг и вообще не отвечает. Тогда сервер будет до посинения слать fin'ы каждые retransmission timeout секунд?

не, попробует несколько раз и закроет коннекшн

афаик будет ретрансмитить до TCP_USER_TIMEOUT (смотри rfc5482 ), таймаут устанавливается через setsockopt на сокете, а если он не установлен то будет ждать в зависимости от настроек tcp keepalive ( http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html )

Ну вот в чём прикол: на старых ядрах нету TCP_USER_TIMEOUT, а keepalive по умолчанию 2 часа. Т.е. можно DoS организовать путем открытия соединения (инициатор - клиент), потом закрытие на инициаторе, без реакции на последний FIN (от сервера). Тогда на серваке будут 100500 повисших коннектов в состоянии last_ack. Так?

Если мне не изменяет склероз то логически сокет закроется уже после отправки FIN от сервера, и состояние last_ack, повторная отправка FIN в ответ на отсутствующий ack это уже стезя стека tcp/ip. Т.е. в юзермоде сокет будет закрыт, а как ядро ( стек tcp/ip ) это разрулит я хз, надо сорцы глядеть, а мне лениво.

У меня есть вот такая картинка, может поможет разобраться.

Судя по картинке, если ack не прилетит, то серверный сокет зависнет форэва энд эва в состоянии last_ack. В чём и вопрос. Это же атака для хацкеров.

Each peer may terminate data transmission at any time by sending a packet with the FIN bit. A FIN represents the end of the data (like an end-of-file indication). The FIN is acknowledged, advancing the sequence number by 1. The connection may continue to carry data in the other direction until a FIN is sent in that direction. The acknowledgment of that FIN terminates the connection. To guarantee synchronization at the conclusion of the connection, the peer sending the last ACK of a FIN must retain state long enough that any retransmitted FIN packets would have reached it or have been discarded; otherwise, if the ACK were lost and a retransmitted FIN were received, the receiver would be unable to repeat the acknowledgment. This interval is arbitrarily set to twice the maximum expected segment lifetime (known as 2MSL).

-- source: ISBN: 0-201-54979-4

неблокируемые сокеты

To guarantee synchronization at the conclusion of the connection, the peer sending the last ACK of a FIN must retain state long enough that any retransmitted FIN packets would have reached it or have been discarded; otherwise, if the ACK were lost and a retransmitted FIN were received, the receiver would be unable to repeat the acknowledgment.

Это не про LAST_ACK, а про TIME_WAIT.

Это же атака для хацкеров.

Если у атакующего есть в распоряжении ботнет, при помощи которого он может полностью устанавливать TCP-соединения, почему бы ему не работать уже на уровне приложения, пожирая гораздо большее количество ресурсов, чем просто аллоцирование TCB?

Олсо, по поводу LAST_ACK: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=25986