LINUX.ORG.RU

Вопрос по tcp/ip

 ,


0

2

В момент закрытия сокета удалённой (клиент) стороной соединение сервера может перейти в состояние last_ack. Если последний ack никогда не придёт, сработает ли таймаут для закрытия сокета сервера? Если да, то где в /proc этот параметр можно вычитать?

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

nokachi
()
Ответ на: комментарий от nokachi

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

nerdogeek
() автор топика
Ответ на: комментарий от nerdogeek

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

nokachi
()
Ответ на: комментарий от peacelove

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

nerdogeek
() автор топика
Ответ на: комментарий от nerdogeek

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

peacelove
()
Ответ на: комментарий от beastie

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

nerdogeek
() автор топика
Последнее исправление: nerdogeek (всего исправлений: 1)
Ответ на: комментарий от nerdogeek

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

beastie ★★★★★
()

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

anonymous
()
Ответ на: комментарий от beastie

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.

edigaryev ★★★★★
()
Ответ на: комментарий от nerdogeek

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

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

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

edigaryev ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.