Quoting Alexey Markov <[email protected]>:
Hello, Slawa!
On June, 28 2013 at 12:48 you wrote to [email protected]:
EG>>> закрытое сервером соединение ожидает подтверждения закрытия от
EG>>> клиента, потребляя меньше памяти, чем открытое; таких соединений
EG>>> может быть до sysctl net.inet.tcp.maxtcptw (часть от
EG>>> kern.ipc.maxsockets, поэтому такие сокеты мешают открытию новых);
??>>
??>> С соединениями в состоянии TIME_WAIT всё понятно, и их число вопросов
??>> не вызывает вопросов. Меня больше волнует, что делать с намного
??>> бОльшим числом соединений в состоянии FIN_WAIT_1, и можно ли их чем-то
??>> ограничить?
SO> net.inet.tcp.fast_finwait2_recycle=1
Это тоже стоит, как и net.inet.tcp.finwait2_timeout=5000, но FIN_WAIT_2
- это уже после получения ACK от клиента, и число таких соединений в 50
раз меньше, чем с FIN_WAIT_1.
Основная проблема в том, что после попытки закрытия соединения сервером,
он не получает НИЧЕГО в ответ на свой FIN, и в итоге получается туева хуча
соединений в состоянии FIN_WAIT_1, которые рано или поздно упираются в
системный лимит. А способа подкрутить таймаут для них, как для FIN_WAIT_2,
я так и не нашёл. :-(
Вы все же попробуйте подойти к этой проблеме с несколько другой стороны.
Попробуйте проанализировать отличия в трафике от ботов и нормальных
клиентов. Анализируйте все - диапазоны портов, используемых для
открытия соединения, TTL, флажки - просто все. Если найдете
закономерность, пригодную к использованию в stateless firewall -
отмычка у Вас в кармане.
Можно было бы ограничивать число коннектов с одного IP через ipfw, но меня
смущает, не станет ли огромное количество динамических правил просто другим
способом устроить DDoS?
P.S.
Уговорите пожалуйста Ваш MUA верно кодировать 8-битные символы в Subject..
--
WBR, Alexey Markov.
